Updates and figures for PEP 458 and PEP 480 by Vladimir Diaz.

pep-0458.txt

@@ -3,7 +3,7 @@ Title: Surviving a Compromise of PyPI
 Version: $Revision$
 Last-Modified: $Date$
 Author: Trishank Karthik Kuppusamy <trishank@nyu.edu>,
-        Vladimir Diaz <vd558@nyu.edu>,
+        Vladimir Diaz <vladimir.diaz@nyu.edu>,
         Donald Stufft <donald@stufft.io>, Justin Cappos <jcappos@nyu.edu>
 BDFL-Delegate: Richard Jones <r1chardj0n3s@gmail.com>
 Discussions-To: DistUtils mailing list <distutils-sig@python.org>
@@ -44,12 +44,11 @@ interested in adopting TUF on the client side may consult TUF's `library
 documentation`__, which exists for this purpose.  Support for project
 distributions that are signed by developers (maximum security model) is also
 not discussed in this PEP, but is outlined in the appendix as a possible future
-extension and covered in detail in PEP X [VD: Link to PEP once it is
-completed].  The PEP X extension focuses on the maximum security model, which
-requires more PyPI administrative work (none by clients), but it also proposes
-an easy-to-use key management solution for developers, how to interface with a
-potential future build farm on PyPI infrastructure, and discusses the
-feasibility of end-to-end signing.
+extension and covered in detail in PEP 480 [26]_.  The PEP 480 extension
+focuses on the maximum security model, which requires more PyPI administrative
+work (none by clients), but it also proposes an easy-to-use key management
+solution for developers, how to interface with a potential future build farm on
+PyPI infrastructure, and discusses the feasibility of end-to-end signing.
 
 __ https://github.com/theupdateframework/tuf/tree/develop/tuf/client#updaterpy
 
@@ -164,9 +163,8 @@ Terms used in this PEP are defined as follows:
 * Metadata: Metadata are signed files that describe roles, other metadata, and
   target files.
 
-* Repository: A repository is a resource compromised of named metadata and
-  target files.  Clients request metadata and target files stored on a
-  repository.
+* Repository: A repository is a resource comprised of named metadata and target
+  files.  Clients request metadata and target files stored on a repository.
 
 * Consistent snapshot: A set of TUF metadata and PyPI targets that capture the
   complete state of all projects on PyPI as they existed at some fixed point in
@@ -302,7 +300,7 @@ available target files (in our case, it will be all files on PyPI under the
 responsibilities without exception.  Figure 1 provides a table of the roles
 used in TUF.
 
-.. image:: figure1.png
+.. image:: pep-0458/figure1.png
 
 Figure 1: An overview of the TUF roles.
 
@@ -322,7 +320,7 @@ also indicates the types of keys used to sign each role and which roles are
 trusted to sign for files available on PyPI.  The next two sections cover the
 details of signing repository files and the types of keys used for each role.
 
-.. image:: figure2.png
+.. image:: pep-0458/figure2.png
 
 Figure 2: An overview of the role metadata available on PyPI.
 
@@ -743,10 +741,9 @@ attack other than a freeze attack, one must also compromise the *snapshot* key.
 
 Finally, a compromise of the PyPI infrastructure MAY introduce malicious
 updates to *bins* projects because the keys for these roles are online.  The
-maximum security model discussed in the appendix addresses this issue.  PEP X
-[VD: Link to PEP once it is completed] also covers the maximum security model
-and goes into more detail on generating developer keys and signing uploaded
-distributions.
+maximum security model discussed in the appendix addresses this issue.  PEP 480
+also covers the maximum security model and goes into more detail on generating
+developer keys and signing uploaded distributions.
 
 
 In the Event of a Key Compromise
@@ -908,10 +905,10 @@ The maximum security model and end-to-end signing have been intentionally
 excluded from this PEP.  Although both improve PyPI's ability to survive a
 repository compromise and allow developers to sign their distributions, they
 have been postponed for review as a potential future extension to PEP 458.  PEP
-X [VD: Link to PEP once it is completed], which discusses the extension in
-detail, is available for review to those developers interested in the
-end-to-end signing option.  The maximum security model and end-to-end signing
-are briefly covered in subsections that follow.
+480 [26]_, which discusses the extension in detail, is available for review to
+those developers interested in the end-to-end signing option.  The maximum
+security model and end-to-end signing are briefly covered in subsections that
+follow.
 
 There are several reasons for not initially supporting the features discussed
 in this section:
@@ -960,7 +957,7 @@ all of the projects are signed by an online key.  An attacker can corrupt
 packages in the minimum security model, but not in the maximum model without
 also compromising a developer's key.
 
-.. image:: figure3.png
+.. image:: pep-0458/figure3.png
 
 Figure 3: An overview of the metadata layout in the maximum security model.
 The maximum security model supports continuous delivery and survivable key
@@ -975,15 +972,15 @@ downloaded by clients.  PyPI is trusted to make uploaded projects available to
 clients (they sign the metadata for this part of the process), and developers
 can sign the distributions that they upload.
 
-PEP X [VD: Link to PEP once it is completed] discusses the tools available to
-developers who sign the distributions that they upload to PyPI.  To summarize
-PEP X, developers generate cryptographic keys and sign metadata in some
-automated fashion, where the metadata includes the information required to
-verify the authenticity of the distribution.  The metadata is then uploaded to
-PyPI by the client, where it will be available for download by package managers
-such as pip (i.e., package managers that support TUF metadata).  The entire
-process is transparent to clients (using a package manager that supports TUF)
-who download distributions from PyPI.
+PEP 480 [26]_ discusses the tools available to developers who sign the
+distributions that they upload to PyPI.  To summarize PEP 480, developers
+generate cryptographic keys and sign metadata in some automated fashion, where
+the metadata includes the information required to verify the authenticity of
+the distribution.  The metadata is then uploaded to PyPI by the client, where
+it will be available for download by package managers such as pip (i.e.,
+package managers that support TUF metadata).  The entire process is transparent
+to clients (using a package manager that supports TUF) who download
+distributions from PyPI.
 
 
 Appendix C: PEP 470 and Projects Hosted Externally
@@ -1065,6 +1062,7 @@ References
 .. [23] https://www.openssl.org/
 .. [24] https://pypi.python.org/pypi/pycrypto
 .. [25] http://ed25519.cr.yp.to/
+.. [26] https://www.python.org/dev/peps/pep-0480/
 
 Acknowledgements
 ================

pep-0480.txt

@@ -3,7 +3,7 @@ Title: Surviving a Compromise of PyPI: The Maximum Security Model
 Version: $Revision$
 Last-Modified: $Date$
 Author: Trishank Karthik Kuppusamy <trishank@nyu.edu>,
-        Vladimir Diaz <vd558@nyu.edu>, Donald Stufft <donald@stufft.io>,
+        Vladimir Diaz <vladimir.diaz@nyu.edu>, Donald Stufft <donald@stufft.io>,
         Justin Cappos <jcappos@nyu.edu>
 BDFL-Delegate: Richard Jones <r1chardj0n3s@gmail.com>
 Discussions-To: DistUtils mailing list <distutils-sig@python.org>
@@ -186,7 +186,7 @@ projects are signed by an online key.  That is, an attacker is able to corrupt
 packages in the minimum security model, but not in the maximum model, without
 also compromising a developer's key.
 
-.. image:: figure1.png
+.. image:: pep-0480/figure1.png
 
 Figure 1: An overview of the metadata layout in the maximum security model.
 The maximum security model supports continuous delivery and survivable key