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

[Donald Stufft]

> On Dec 10, 2014, at 10:16 PM, Vladimir Diaz <vladimir.v.diaz at gmail.com> wrote:
> 
> Hello everyone,
> 
> I am a research programmer at the NYU School of Engineering.  My colleagues (Trishank Kuppusamy and Justin Cappos) and I are requesting community feedback on our proposal, "Surviving a Compromise of PyPI."  The two-stage proposal can be reviewed online at:
> 
> PEP 458
> http://legacy.python.org/dev/peps/pep-0458/ <http://legacy.python.org/dev/peps/pep-0458/>
> 
> PEP 480
> http://legacy.python.org/dev/peps/pep-0480/ <http://legacy.python.org/dev/peps/pep-0480/>
> 


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).

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150102/e2b2d2dc/attachment.html>