On 3 January 2015 at 00:25, Donald Stufft <don...@stufft.io> wrote: > > On Dec 10, 2014, at 10:16 PM, Vladimir Diaz <vladimir.v.d...@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/ > > PEP 480 > 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. >
+1 from me - being able to resolve them in that order was my main motivation for suggesting they be split apart into separate proposals. I just don't personally have any major open questions for PEP 458 - while I'm aware there are some significant technical details to be resolved in terms of exactly what gets signed, and how the implementation will work in practice, I think the concept is sound, and I don't have the necessary knowledge of pip and PyPI internals to have an opinion on the details of the integration. For PEP 480, by contrast, I still have some fundamental questions about whether we should go with a model of "additional developer managed secrets" (the PEP 480 approach, where developers register an additional authentication token for uploads with the PyPI administrators that mean compromising PyPI doesn't grant the ability to do fake uploads for a service) or "additional developer managed accounts" (my new suggestion in this thread, where we collaborate with other organisations like Linux distributions and the OpenStack Foundation for federated validation of critical uploads). While the two approaches are mathematically equivalent, I suspect they're profoundly different in terms of how easy it will be for folks to grasp the relevant security properties. > 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). > Resolving PEP 458 first was my intention when I made the proposal to split them. I only brought the broader PEP 480 proposal into question because the validation server based design finally started to click for me earlier today. > 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), > IIRC, the current draft of the snapshotting mechanism relied heavily on your input regarding what was feasible in the context of the PyPI API design. > 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. > If the TUF folks are amenable, I think that would be great. You've been through the PEP process a few times now, and are probably far more familiar with what's involved in creating a robust PEP than you might wish ;) > 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). > Yep. I'll make one more post to try to clarify why I see separate validation services as having the potential to offer a superior UX in a PEP 480 context, but I'm not pushing for a short term decision on that one - I'm just aiming to plant the seeds of ideas that may be worth keeping in mind as we work on PEP 458. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
