Skip to content

Commit c6fa903

Browse files
mnm678ncoghlan
authored andcommitted
1 parent 99dd06f commit c6fa903

File tree

1 file changed

+47
-0
lines changed

1 file changed

+47
-0
lines changed

pep-0458.txt

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,53 @@ Created: 27-Sep-2013
2222
Abstract
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+
2572
This PEP proposes how The Update Framework [2]_ (TUF) should be integrated with the
2673
Python Package Index (PyPI [1]_). TUF was designed to be a flexible
2774
security add-on to a software updater or package manager. The framework

0 commit comments

Comments
 (0)