PEP 480: Surviving a Compromise of PyPI: End-to-end signing of packages

PEPs
#1

In light of the progress toward implementing PEP 458, we are updating PEP 480 to reflect changes to PEP 458 and to the Warehouse ecosystem since the PEP was first authored. We are hoping to reopen the discussion about approval, and would appreciate any feedback on the PEP as we begin this process.

PEP 480 proposes extending the use of TUF to allow for end-to-end signing of packages. It builds onto the existing work in PEP 458 to allow for developer signing of packages. There is more detail in the PEP.

4 Likes
#2

Some of the high-level items we’ve identified to work on to improve the PEP are:

  • Restructure the PEP so that it’s easier to follow the two main areas of change – 1) changes to Warehouse/PyPI and the administrator workflow 2) changes to developer worfklow and required tooling to support end-to-end signing.
  • Revising the key management solution and proposing something more concrete, both so that it’s easier to implement the PEP (through having a concrete recommendation) and because miniLock isn’t as prevalent today.
  • Clarify recommendations against key sharing.
2 Likes
#3

I opened a pr to address key sharing. It clarifies the recommendation against sharing keys, and adds a mechanism for multiple maintainers to sign a package.

#4

Thanks Marina, this seems like a good addition.

I’m worried what a developer having multiple identities (for each machine they want to sign from) does to the threshold signature scheme. Are we just relying on those trusted with signing authority not to game the threshold system (I think so)?

#5

Yes, it relies on trusting the developers. Projects could increase the threshold to reduce the impact of a developer with multiple signing keys, but the person responsible for increasing the threshold would likely be the same person responsible for the keys, so I don’t see an advantage to requiring additional signatures in this case (although a higher threshold can and should be used to mitigate the impact of a key compromise).

In general, I think it is safe assume that the project maintainers are trusted with regards to their project, and thus give them some freedom to set parameters.

1 Like
#6

I think the nascent sigstore project might be a good solution for the developer key management gap in the current PEP.

They plan to have a WebPKI which authenticates through OpenID Connect and generates a short-lived certificate binding an ephemeral key pair to the ID – resulting in a proof that the artefact was signed by the owner of an email address during the grant window. The public key will be pushed to a transparent log (Rekor) and the same client tooling that enables key generation will also enable simple verification of entries in the transparent log.

Aside: I still owe PEP 480 some edits, I have not forgotten. I hope to get to it in the coming weeks and then move on to looking at whether we might leverage sigstore.