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