On Dec 10, 2014, at 10:16 PM, Vladimir Diaz email@example.com wrote:
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:
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:
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