PEP 740: initial feedback (#3637)

Signed-off-by: William Woodruff <[email protected]>

Author: woodruffw

peps/pep-0740.rst

@@ -33,8 +33,8 @@ it make a policy recommendation around mandatory digital attestations on
 release uploads or their subsequent verification by installing clients like
 ``pip``.
 
-Rationale
-=========
+Rationale and Motivation
+========================
 
 Desire for digital signatures on Python packages has been repeatedly
 expressed by both package maintainers and downstream users:
@@ -49,6 +49,40 @@ expressed by both package maintainers and downstream users:
 
 This proposal seeks to accommodate each of the above use cases.
 
+Additionally, this proposal identifies the following motivations:
+
+* Verifiable provenance for Python package distributions: many Python
+  packages currently contain *unauthenticated* provenance metadata, such
+  as URLs for source hosts. A cryptographic attestation format could enable
+  strong *authenticated* links between these packages and their source hosts,
+  allowing both the index and downstream users to cryptographically verify that
+  a package originates from its claimed source repository.
+* Raising attacker requirements: an attacker who seeks to take
+  over a Python package can be described along *sophistication*
+  (unsophisticated to sophisticated) and *targeting* dimensions
+  (opportunistic to targeted).
+
+  Digital attestations impose additional sophistication requirements: the
+  attacker must be sufficiently sophisticated to access private signing material
+  (or signing identities). They also impose additional targeting requirements:
+  the release consistency requirement (mentioned below) means that the attacker
+  cannot upload *any* attestation, but only one of a type already seen for a
+  particular release. In the future, this could be further "ratcheted" down
+  by allowing project maintainers to disable releases without attestations
+  entirely.
+* Release consistency: in the status quo, the only attestation provided by the
+  index is an optional PGP signature per release file
+  (see :ref:`PGP signatures <pgp-signatures>`). These signatures are not
+  checked by the index either for well-formedness or for validity, since
+  the index has no mechanism for identifying the right public key for the
+  signature.
+
+  Additionally, the index does not have an "all or none" requirement
+  for PGP signatures, meaning that there is no consistency requirement
+  between distributions within a release (and that maintainers may
+  accidentally forget to upload signatures when adding additional
+  release distributions).
+
 While this PEP does not recommend a specific digital attestation format,
 it does recognize the utility of Trusted Publishing as a pre-existing,
 "zero-configuration" source of strong provenance for Python packages.
@@ -109,6 +143,8 @@ areas of Python packaging:
 Previous Work
 -------------
 
+.. _pgp-signatures:
+
 PGP signatures
 ^^^^^^^^^^^^^^
 
@@ -260,6 +296,10 @@ JSON-based Simple API
   ``provenance`` object in the ``file`` dictionary for that file.
 * ``provenance``, when present, **MUST** be a :ref:`provenance object <provenance-object>`.
 
+These changes require a version change to the JSON API:
+
+* The ``api-version`` must specify version 1.2 or later.
+
 Security Implications
 =====================