@@ -239,11 +239,13 @@ downloaded by clients. PyPI is trusted to make uploaded projects available to
239
239
clients (PyPI signs the metadata for this part of the process), and developers
240
240
sign the distributions that they upload to PyPI.
241
241
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
244
246
metadata that PyPI then signs. After the initial trust is established,
245
247
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
247
249
developers upload to PyPI includes information like the distribution's file
248
250
size and hash, which package managers use to verify distributions that are
249
251
downloaded.
@@ -368,7 +370,8 @@ A default, PyPI-mediated key management and package signing solution that is
368
370
`transparent`__ to developers and does not require a key escrow (sharing of
369
371
encrypted private keys with PyPI) is RECOMMENDED for the signing tools.
370
372
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.
372
375
373
376
__ https://en.wikipedia.org/wiki/Transparency_%28human%E2%80%93computer_interaction%29
374
377
@@ -380,6 +383,8 @@ follow to upload a distribution to PyPI:
380
383
3. Optional: Add a new identity to the developer's PyPI user account from a
381
384
second machine (after a password prompt).
382
385
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.
383
388
384
389
Step 1 is the normal procedure followed by developers to `register a PyPI
385
390
project`__.
@@ -392,7 +397,7 @@ to PyPI, and signs the TUF metadata that is generated for the distribution.
392
397
Optionally adding a new identity from a second machine, by simply entering a
393
398
password, in step 3 also generates an encrypted private key file and uploads an
394
399
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.
396
401
An existing verified identity (its public key is contained in project metadata
397
402
or has been uploaded to PyPI) signs for new identities. By default, project
398
403
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
402
407
Process" section discusses in detail the procedure followed by developers to
403
408
upload a distribution to PyPI.
404
409
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
+
405
414
Generation of cryptographic files and signatures is transparent to the
406
415
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 .
410
419
411
420
The `repository`__ and `developer`__ TUF tools currently support all of the
412
421
recommendations previously mentioned, except for the automated signing
0 commit comments