<div dir="ltr"><div><div><div>::ping::<br><br></div>Has anyone in the community gotten a chance to review PEP 458 and/or PEP 480?  Community feedback would be appreciated.<br><br></div>Thanks,<br></div>Vlad<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 10:16 PM, Vladimir Diaz <span dir="ltr"><<a href="mailto:vladimir.v.diaz@gmail.com" target="_blank">vladimir.v.diaz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello everyone,<br><br></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><div><br>PEP 458<br><a href="http://legacy.python.org/dev/peps/pep-0458/" target="_blank">http://legacy.python.org/dev/peps/pep-0458/</a><br><br>PEP 480<br><a href="http://legacy.python.org/dev/peps/pep-0480/" target="_blank">http://legacy.python.org/dev/peps/pep-0480/</a><br><br><br>Summary of the Proposal:<br><br>"Surviving
 a Compromise of PyPI" proposes how the Python Package Index (PyPI) can 
be 
amended to better protect end users from altered or malicious packages, 
and to minimize the extent of PyPI compromises against affected users.  
The proposed integration allows package managers such as pip to be more 
secure against various types of security attacks on PyPI and defend end
 users from attackers responding to package requests. Specifically, 
these PEPs describe how PyPI processes should be adapted to generate and
 incorporate repository metadata, which are signed text files that 
describe the packages and metadata available on PyPI.  Package managers request (along with the packages) the metadata on PyPI to 
verify the authenticity of packages before they are installed.  The 
changes to PyPI and 
tools will be minimal by leveraging a library, <a href="https://github.com/theupdateframework/tuf" target="_blank">The Update Framework</a>, that generates and transparently validates the relevant metadata.<br><br>The first stage of the proposal (<a href="http://legacy.python.org/dev/peps/pep-0458/" target="_blank">PEP 458</a>) uses
 a basic security model that supports verification of PyPI packages 
signed with cryptographic keys stored on PyPI, requires no 
action from developers and end users, and protects against malicious 
CDNs and public mirrors. To support continuous delivery of uploaded 
packages, PyPI administrators sign for uploaded packages with an online key 
stored on PyPI infrastructure. This level of security prevents packages 
from being accidentally or deliberately tampered with by a mirror or a 
CDN because the mirror or CDN will not have any of the keys required to 
sign for projects.  <div><br>The second stage of the proposal (<a href="http://legacy.python.org/dev/peps/pep-0480/" target="_blank">PEP 480</a>)
 is an extension to the basic security model (discussed in PEP 458) that 
supports end-to-end verification of signed packages. End-to-end signing 
allows both PyPI and developers to sign for the packages that are 
downloaded by end users.  If the PyPI infrastructure were to be 
compromised, attackers would be unable to serve malicious versions of 
these packages without access to the project's developer key.  As in PEP
 458, no additional action is required by end users.  However, PyPI administrators will need to periodically (perhaps 
every few months) sign metadata with an offline key.  PEP 480 also 
proposes an easy-to-use key management solution for developers, how to 
interface with a potential build farm on PyPI infrastructure, and 
discusses the security benefits of end-to-end signing.  The second stage of the proposal 
simultaneously supports real-time project registration and developer 
signatures, and when configured to maximize security on PyPI, less than 
1% of end users will be at risk even if an attacker controls PyPI and goes undetected for a month.<br><br>We
 thank Nick Coghlan and Donald Stufft for their valuable contributions, 
and Giovanni Bajo and Anatoly Techtonik for their feedback.<br><br>Thanks,<br>PEP 458 & 480 authors.</div></div></div>
<br>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div><br></div>