::ping:: Has anyone in the community gotten a chance to review PEP 458 and/or PEP 480? Community feedback would be appreciated.
Thanks, Vlad On Wed, 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/ > > > Summary of the Proposal: > > "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, The Update Framework > <https://github.com/theupdateframework/tuf>, that generates and > transparently validates the relevant metadata. > > The first stage of the proposal (PEP 458 > <http://legacy.python.org/dev/peps/pep-0458/>) 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. > > The second stage of the proposal (PEP 480 > <http://legacy.python.org/dev/peps/pep-0480/>) 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. > > We thank Nick Coghlan and Donald Stufft for their valuable contributions, > and Giovanni Bajo and Anatoly Techtonik for their feedback. > > Thanks, > PEP 458 & 480 authors. > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig