[Python-checkins] peps: Updates and figures for PEP 458 and PEP 480 by Vladimir Diaz.

guido.van.rossum python-checkins at python.org
Tue Nov 25 18:45:55 CET 2014


https://hg.python.org/peps/rev/59259922c4f2
changeset:   5614:59259922c4f2
user:        Guido van Rossum <guido at python.org>
date:        Tue Nov 25 09:45:28 2014 -0800
summary:
  Updates and figures for PEP 458 and PEP 480 by Vladimir Diaz.

files:
  pep-0458.txt         |   58 ++++++++++++++----------------
  pep-0458/figure1.png |  Bin 
  pep-0458/figure2.png |  Bin 
  pep-0458/figure3.png |  Bin 
  pep-0480.txt         |    4 +-
  pep-0480/figure1.png |  Bin 
  6 files changed, 30 insertions(+), 32 deletions(-)


diff --git a/pep-0458.txt b/pep-0458.txt
--- a/pep-0458.txt
+++ b/pep-0458.txt
@@ -3,7 +3,7 @@
 Version: $Revision$
 Last-Modified: $Date$
 Author: Trishank Karthik Kuppusamy <trishank at nyu.edu>,
-        Vladimir Diaz <vd558 at nyu.edu>,
+        Vladimir Diaz <vladimir.diaz at nyu.edu>,
         Donald Stufft <donald at stufft.io>, Justin Cappos <jcappos at nyu.edu>
 BDFL-Delegate: Richard Jones <r1chardj0n3s at gmail.com>
 Discussions-To: DistUtils mailing list <distutils-sig at python.org>
@@ -44,12 +44,11 @@
 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 @@
 * 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 @@
 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 @@
 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 @@
 
 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 @@
 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 @@
 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 @@
 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 @@
 .. [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
 ================
diff --git a/pep-0458/figure1.png b/pep-0458/figure1.png
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..b08801b5841cd35da8f719549e2c5377793e35f1
GIT binary patch
[stripped]
diff --git a/pep-0458/figure2.png b/pep-0458/figure2.png
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cb535f631bcb8277ef9c3e4e4bc4f9a0765b5519
GIT binary patch
[stripped]
diff --git a/pep-0458/figure3.png b/pep-0458/figure3.png
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..a31edf1702d26556382973306a8f216e7f304418
GIT binary patch
[stripped]
diff --git a/pep-0480.txt b/pep-0480.txt
--- a/pep-0480.txt
+++ b/pep-0480.txt
@@ -3,7 +3,7 @@
 Version: $Revision$
 Last-Modified: $Date$
 Author: Trishank Karthik Kuppusamy <trishank at nyu.edu>,
-        Vladimir Diaz <vd558 at nyu.edu>, Donald Stufft <donald at stufft.io>,
+        Vladimir Diaz <vladimir.diaz at nyu.edu>, Donald Stufft <donald at stufft.io>,
         Justin Cappos <jcappos at nyu.edu>
 BDFL-Delegate: Richard Jones <r1chardj0n3s at gmail.com>
 Discussions-To: DistUtils mailing list <distutils-sig at python.org>
@@ -186,7 +186,7 @@
 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
diff --git a/pep-0480/figure1.png b/pep-0480/figure1.png
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..a31edf1702d26556382973306a8f216e7f304418
GIT binary patch
[stripped]

-- 
Repository URL: https://hg.python.org/peps


More information about the Python-checkins mailing list