[pre-RFC] Using Sigstore for signing and verifying crates

@Eh2406 asymmetric tokens and Sigstore should work well together with proper domain separation.

If integrated successfully, you should be able to leverage Rektor to maintain an audit log of an ephemeral asymmetric key tied to a particular OIDC principal (which in the case of crates.io might be limited to GitHub users to get started) which can be tied both to an asymmetric token and used for codesigning (where Rektor applies to the latter).

1 Like

Given the pricing and that I need none of the Enterprise features…

I'm glad they can be made to work well together, but so can plane tokens and code signing. I don't think I see what the difference in domains are, it feels like they both carry the same information. If on publish cargo is sending an Asymmetric Token and signing the code using the same key, what information is the asymmetric token adding to the interaction? crates.io can ignore the token and just read all the same information out of the codesigning or its associated transparency log and metadata.

I'm wondering if for shared ownership, since a crate owner can be a GitHub team within an organizations, the UI could derive the possible signing identities from team members and then select which ones would be allowed.

1 Like

The discussion on e-mail as identities is really interesting, thanks to everyone contributing to that!

To summarize: The problem with e-mail identities is not whether or not we require them for signing, but if we can delete them from the transparency log to comply with right to be forgotten. E-mail is personal data, ergo it must be deleteable or 'masked' if added to the transparency log.

So I think we could do one of three options going forward:

  1. Bet on the transparency log/Rekor to gain support for anonymization and/or removing entries?
  2. Rely on some way to hide/mask the e-mail in a secure way? I see Key Transparency as a way to do that.
  3. Not use e-mail, but instead require CI/CD claims from systems like GitHub actions?

My impression is that 1. and 2. is a blocker for e-mail as identities.

So maybe instead starting with supporting 3. (similar to NPM) would give some time to adopt signing and verification process for users. IMHO it would cover a lot of the needs for those who care about signing and verification to begin with.

FWIW I've been asking the Sigstore people about this. A verifiable random function can be used to deterministically tokenize email addresses into a random-looking string ala Key Transparency.


I brought this suggestion up on the SigStore slack, where an interesting conversation was had. Slack TLDR: there would be practical problems with a registry that used SigStore as it's only kind of identity, and even more practical problems with using TUF as the only kind of authorization. But it makes sense in theory, and a lot of people are experimenting with how to make it feasible in practice.

On a different note, a bunch of useful links were gathered together at Produce cryptographic signing guide for package managers · Issue #10 · ossf/wg-securing-software-repos · GitHub about how to adopt SigStore and related tools.


Thank you all for the feedback! I've taken note of the following to be improved in the RFC:

  • How PII is handled using workload identities and anonymized e-mail as identities, with alternatives discussed.
  • Authorization: How to deal with authorization on crates.io and showing how this can be done in a future enhancement with TUF.
  • Future enhancement on using TUF for additional signatures from crates.io itself and signing the index.
  • Advice on why crates.io should use a separate identity from GitHub in addition to the Sigstore identity.

I'll notify once it's ready for another look. Anyone who'd like to improve the RFC are welcome to do so by submitting a PR to the repo!


For reference a RFC was posted at https://github.com/rust-lang/rfcs/pull/3403


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.