[Distutils] Surviving a Compromise of PyPI - PEP 458 and 480

[Vladimir Diaz]

Thanks for the great feedback - Nick, Donald, Paul, and Richard (off-list).

I am totally fine with focusing on PEP 458 and applying the final coat of
paint on this document.

There's a lot of background documentation and technical details excluded
from the PEPs (to avoid turning the PEP into a 15+ page behemoth), but I do
agree that we should explicitly cover some of these implementation details
in PEP 458.  Subsections on the exact format of metadata, explanation on
how metadata is signed, and how the roles are "delegated" with the library,
still remain.  As Paul as indicated, terminology can also be improved so as
to be more readable for "non-experts."

Let me know how we should collaborate on PEP 458 going forward.  Guido van
Rossum made minor corrections to PEP 458, and requested we reflect his
changes back to the version on Github.  We can either move
hg.python.org/pep/pep-0458.txt
<https://hg.python.org/peps/file/a532493ba99c/pep-0458.txt> to
github.com/pypa or github.com/theupdateframework/pep-on-pypi-with-tuf.

Thanks,
Vlad

On Fri, Jan 2, 2015 at 10:31 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 2 January 2015 at 14:25, Donald Stufft <donald at stufft.io> wrote:
> > I’m going through the PEPs again, and I think that evaluating these PEPs
> is
> > more complicated by the fact that there is two of them, I agree that
> > splitting
> > up the two PEPs was the right thing to do though. What do you think about
> > putting PEP 480 on the back burner for the moment and focus on PEP 458.
> >
> > I think this will benefit the process in a few ways:
> >
> > * I believe that PEP 458 is far less controversial than PEP 480 since
> it’s
> >   effectively just exchanging TLS for TUF for verification and other than
> >   for the authors of the tools who need to work with it (pip, devpi,
> >   bandersnatch, PyPI, etc) it’s transparent for the end users.
> > * It allows us to discuss the particulars of getting TUF integrated in
> PyPI
> >   without worrying about the far nastier problem of exposing a signing
> UX to
> >   end authors.
> > * While discussing it, we can still ensure that we leave ourselves enough
> >   flexibility so that we don’t need to make any major changes for PEP
> 480.
> > * The problems that are going to crop up while implementing it (is the
> >   mirror protocol good enough? CDN Purging? Etc) are mostly likely to
> happen during
> >   PEP 458.
> > * I think having them both being discussed at the same time is causing a
> lot
> >   of confusion between which proposal does what.
> > * By focusing on one at a time we can get a more polished PEP that is
> easier
> >   to understand (see below).
> >
> > Overall I think the PEPs themselves need a bit of work, they currently
> rely
> > a lot on reading the TUF white paper and the TUF spec in the repository
> to get
> > a grasp of what’s going on. I believe they also read more like
> suggestions
> > about how we might go about implementing TUF rather than an actionable
> plan
> > for implementing TUF. I’ve seen feedback from more than one person that
> they
> > feel like they are having a hard time grok’ing what the *impact* of the
> PEPs will
> > be to them without having to go through and understand the intricacies
> of TUF
> > and how the PEP implements TUF.
> >
> > Technically I’m listed on this PEP as an author (although I don’t
> remember
> > anymore what I did to get on there :D), but I care a good bit about
> getting
> > something better than TLS setup, so, if y’all are willing to defer PEP
> 480
> > for right now and focus on PEP 458 and y’all want it, I’m willing to
> actually
> > earn that co-author spot and help get PEP 458 into shape and help get it
> > accepted and implemented.
> >
> > Either way though, I suggest focus on PEP 458 (with an eye towards not
> > making any decisions which will require changes on the client side to
> implement
> > PEP 480).
>
> +1 on all of this.
>
> I agree that PEP 458 is (relatively speaking) an obvious thing to do,
> and if the people who have to do the work for it are happy, I think it
> should just go ahead.
>
> I'd like to see the PEPs reworded a bit to be less intimidating to the
> non-specialist. For PEPs about the trust model for PyPI, it's ironic
> that I have to place a lot of trust in the PEP authors simply because
> I don't understand half of what they are saying ;-)
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150102/5cfc0cea/attachment-0001.html>