<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2014, at 10:16 PM, Vladimir Diaz <<a href="mailto:vladimir.v.diaz@gmail.com" class="">vladimir.v.diaz@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hello everyone,<br class=""><br class=""></div>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:<br class=""><div class=""><br class="">PEP 458<br class=""><a href="http://legacy.python.org/dev/peps/pep-0458/" target="_blank" class="">http://legacy.python.org/dev/peps/pep-0458/</a><br class=""><br class="">PEP 480<br class=""><a href="http://legacy.python.org/dev/peps/pep-0480/" target="_blank" class="">http://legacy.python.org/dev/peps/pep-0480/</a><br class=""><br class=""></div></div></div></blockquote></div><div class=""><br class=""></div><div class=""><div class="">I’m going through the PEPs again, and I think that evaluating these PEPs is</div><div class="">more complicated by the fact that there is two of them, I agree that splitting</div><div class="">up the two PEPs was the right thing to do though. What do you think about</div><div class="">putting PEP 480 on the back burner for the moment and focus on PEP 458.</div><div class=""><br class=""></div><div class="">I think this will benefit the process in a few ways:</div><div class=""><br class=""></div><div class="">* I believe that PEP 458 is far less controversial than PEP 480 since it’s</div><div class=""> effectively just exchanging TLS for TUF for verification and other than for</div><div class=""> the authors of the tools who need to work with it (pip, devpi, bandersnatch,</div><div class=""> PyPI, etc) it’s transparent for the end users.</div><div class="">* It allows us to discuss the particulars of getting TUF integrated in PyPI</div><div class=""> without worrying about the far nastier problem of exposing a signing UX to</div><div class=""> end authors.</div><div class="">* While discussing it, we can still ensure that we leave ourselves enough</div><div class=""> flexibility so that we don’t need to make any major changes for PEP 480.</div><div class="">* The problems that are going to crop up while implementing it (is the mirror</div><div class=""> protocol good enough? CDN Purging? Etc) are mostly likely to happen during</div><div class=""> PEP 458.</div><div class="">* I think having them both being discussed at the same time is causing a lot of</div><div class=""> confusion between which proposal does what.</div><div class="">* By focusing on one at a time we can get a more polished PEP that is easier to</div><div class=""> understand (see below).</div><div class=""><br class=""></div><div class="">Overall I think the PEPs themselves need a bit of work, they currently rely a</div><div class="">lot on reading the TUF white paper and the TUF spec in the repository to get a</div><div class="">grasp of what’s going on. I believe they also read more like suggestions about</div><div class="">how we might go about implementing TUF rather than an actionable plan for</div><div class="">implementing TUF. I’ve seen feedback from more than one person that they feel</div><div class="">like they are having a hard time grok’ing what the *impact* of the PEPs will be</div><div class="">to them without having to go through and understand the intricacies of TUF and</div><div class="">how the PEP implements TUF.</div><div class=""><br class=""></div><div class="">Technically I’m listed on this PEP as an author (although I don’t remember</div><div class="">anymore what I did to get on there :D), but I care a good bit about getting</div><div class="">something better than TLS setup, so, if y’all are willing to defer PEP 480 for</div><div class="">right now and focus on PEP 458 and y’all want it, I’m willing to actually earn</div><div class="">that co-author spot and help get PEP 458 into shape and help get it accepted</div><div class="">and implemented.</div><div class=""><br class=""></div><div class="">Either way though, I suggest focus on PEP 458 (with an eye towards not making</div><div class="">any decisions which will require changes on the client side to implement PEP</div><div class="">480).</div></div><div class=""><br class=""></div><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>
</div>
<br class=""></body></html>