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

[Paul Moore]

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