iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 458: Add abstract per discussion here: https://discuss.python.org/t/pep-458-surviving-a-compromise-of-pypi/2648/52 (#1268)

This commit is contained in:
mnm678 2020-01-04 21:05:45 -05:00 committed by Nick Coghlan
parent 99dd06f78e
commit c6fa90376e
1 changed files with 47 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
pep-0458.txt
View File

@ -22,6 +22,53 @@ Created: 27-Sep-2013
Abstract Abstract
======== ========
Attacks on software repositories are common, even in organizations with very
good security practices__. The resulting repository compromise allows an
attacker to edit all files stored on the repository and sign these files using
any keys stored on the repository (online keys). In many signing schemes (like
TLS), this access allows the attacker to replace files on the repository and
make it look like these files are coming from PyPI. Without a way to revoke and
replace the trusted private key, it is very challenging to recover from a
repository compromise. In addition to the dangers of repository compromise,
software repositories are vulnerable to an attacker on the network (MITM)
intercepting and changing files. These and other attacks on software
repositories are detailed here__. This PEP aims to protect users of PyPI from
compromises of the integrity, consistency and freshness properties of PyPI
packages, and enhances compromise resilience, by mitigating key risk and
providing mechanisms to recover from a compromise of PyPI or its signing keys.
In addition to protecting direct users of PyPI, this PEP aims to provide similar
protection for users of PyPI mirrors.
To provide compromise resilient protection of PyPI, this PEP proposes the use of
The Update Framework [2]_ (TUF). TUF provides protection from a variety of
attacks on software update systems, while also providing mechanisms to recover
from a repository compromise. TUF has been used in production by a number of
organizations, including use in Cloud Native Computing Foundation’s Notary
service, which provides the infrastructure for container image signing in Docker
Registry. The TUF specification has been the subject of three independent
security audits__.
This PEP describes changes to the PyPI infrastructure that are needed to ensure
that users get valid packages from PyPI. These changes should have minimal
impact on other parts of the ecosystem. The PEP focuses on communication between
PyPI and users, and so does not require any action by package developers.
Developers will upload packages using the current process, and PyPI will
automatically sign these packages. In order for the security mechanism to be
effective, additional work will need to be done by PyPI consumers (like pip) to
verify the signatures and metadata provided by PyPI. This verification can be
transparent to users (unless it fails) and provides an automatic security
mechanism. There is documentation for how to consume TUF metadata in the TUF
repository. However, changes to PyPI consumers are not required, and can be done
according to the timelines and priorities of individual projects.
__ https://github.com/theupdateframework/pip/wiki/Attacks-on-software-repositories
__ https://theupdateframework.github.io/security.html
__ https://theupdateframework.github.io/audits.html
Proposed TUF Integration
========================
This PEP proposes how The Update Framework [2]_ (TUF) should be integrated with the This PEP proposes how The Update Framework [2]_ (TUF) should be integrated with the
Python Package Index (PyPI [1]_). TUF was designed to be a flexible Python Package Index (PyPI [1]_). TUF was designed to be a flexible
security add-on to a software updater or package manager. The framework security add-on to a software updater or package manager. The framework