Skip to content

Commit 73d438c

Browse files
authored
PEP 480: Clarify automated signing solution to remove key sharing (#1711)
1 parent ee52157 commit 73d438c

File tree

1 file changed

+17
-8
lines changed

1 file changed

+17
-8
lines changed

pep-0480.txt

+17-8
Original file line numberDiff line numberDiff line change
@@ -239,11 +239,13 @@ downloaded by clients. PyPI is trusted to make uploaded projects available to
239239
clients (PyPI signs the metadata for this part of the process), and developers
240240
sign the distributions that they upload to PyPI.
241241

242-
In order to delegate trust to a project, developers are required to submit a
243-
public key to PyPI. PyPI takes the project's public key and adds it to parent
242+
In order to delegate trust to a project, developers are required to submit at
243+
least one public key to PyPI. Developers may submit multiple public keys for
244+
the same project (for example, one key for each maintainer of the project).
245+
PyPI takes all of the project's public keys and adds them to parent
244246
metadata that PyPI then signs. After the initial trust is established,
245247
developers are required to sign distributions that they upload to PyPI using
246-
the public key's corresponding private key. The signed TUF metadata that
248+
at least one public key's corresponding private key. The signed TUF metadata that
247249
developers upload to PyPI includes information like the distribution's file
248250
size and hash, which package managers use to verify distributions that are
249251
downloaded.
@@ -368,7 +370,8 @@ A default, PyPI-mediated key management and package signing solution that is
368370
`transparent`__ to developers and does not require a key escrow (sharing of
369371
encrypted private keys with PyPI) is RECOMMENDED for the signing tools.
370372
Additionally, the signing tools SHOULD circumvent the sharing of private keys
371-
across multiple machines of each developer.
373+
across multiple machines of each developer. This means that the key management
374+
solution SHOULD support multiple keys for each project.
372375

373376
__ https://en.wikipedia.org/wiki/Transparency_%28human%E2%80%93computer_interaction%29
374377

@@ -380,6 +383,8 @@ follow to upload a distribution to PyPI:
380383
3. Optional: Add a new identity to the developer's PyPI user account from a
381384
second machine (after a password prompt).
382385
4. Upload project.
386+
5. Optional: Other maintainers associated with the project may log in and
387+
enter a secondary password to add their identity to the project.
383388

384389
Step 1 is the normal procedure followed by developers to `register a PyPI
385390
project`__.
@@ -392,7 +397,7 @@ to PyPI, and signs the TUF metadata that is generated for the distribution.
392397
Optionally adding a new identity from a second machine, by simply entering a
393398
password, in step 3 also generates an encrypted private key file and uploads an
394399
Ed25519 public key to PyPI. Separate identities MAY be created to allow a
395-
developer, or other project maintainers, to sign releases on multiple machines.
400+
developer, to sign releases on multiple machines.
396401
An existing verified identity (its public key is contained in project metadata
397402
or has been uploaded to PyPI) signs for new identities. By default, project
398403
metadata has a signature threshold of "1" and other verified identities may
@@ -402,11 +407,15 @@ Step 4 uploads the distribution file and TUF metadata to PyPI. The "Snapshot
402407
Process" section discusses in detail the procedure followed by developers to
403408
upload a distribution to PyPI.
404409

410+
Step 5 allows other maintainers to generate an encrypted key file, in a similar
411+
manner to step 2. These keys SHOULD be uploaded to PyPI and added to the TUF
412+
metadata. This key MAY be used to upload future releases of the project.
413+
405414
Generation of cryptographic files and signatures is transparent to the
406415
developers in the default case: developers need not be aware that packages are
407-
automatically signed. However, the signing tools should be flexible; a single
408-
project key may also be shared between multiple machines if manual key
409-
management is preferred (e.g., ssh-copy-id).
416+
automatically signed. However, the signing tools should be flexible; developers
417+
may want to generate their own keys and handle the key management themselves.
418+
In this case, the developers may simply upload their public key(s) to PyPI.
410419

411420
The `repository`__ and `developer`__ TUF tools currently support all of the
412421
recommendations previously mentioned, except for the automated signing

0 commit comments

Comments
 (0)