Rust release signing key uses SHA1 self-/binding signatures

[Fabian-Gruenbichler]

Hi!

Debian is currently evaluating switching apt/gpgv over to a gpgv implementation backed by Sequoia instead of gnupg. While test-driving that on my machine, while working on preparing the rustc 1.83 update, which entails downloading and verifying the upstream rustc-src tarball, I noticed that the rustc release signing key fails the default policy of Sequoia, which doesn't accept current signatures derived directly or transitively from SHA-1.

While it's easy enough to work around locally, I thought I'd report it anyway in case you want to update those signatures to a better cryptographic hash algorithm.

Here's the output of sq cert lint <public key> (there also is a --fix parameter, which should regenerate those signatures with better algorithms, but that of course requires access to the corresponding private key material which I lack):

$ sq cert lint --cert-file ./rust/debian/upstream/*.asc
Certificate 85AB96E6FA1BE5FE is not valid under the standard policy: No binding signature at time
2024-11-29T16:07:22Z
Certificate 85AB96E6FA1BE5FE contains a User ID ("Rust Language (Tag and Release Signing Key) <rust-
key@rust-lang.org>") protected by SHA-1
Certificate 85AB96E6FA1BE5FE, key 5CB4A9347B3B09DC uses a SHA-1-protected binding signature.
Certificate 85AB96E6FA1BE5FE, key 8E9AA3F7AB3F5826 uses a SHA-1-protected binding signature.
Examined 1 certificate.
  0 certificates are invalid and were not linted. (GOOD)
  1 certificate was linted.
  1 of the 1 certificates (100%) has at least one issue. (BAD)
0 of the linted certificates were revoked.
  0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
1 of the non-revoked linted certificate has at least one non-revoked User ID:
  1 has at least one User ID protected by SHA-1. (BAD)
  1 has all User IDs protected by SHA-1. (BAD)
1 of the non-revoked linted certificates has at least one non-revoked, live subkey:
  1 has at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable
subkey:
  0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)

note the lines ending with (BAD) that all point to the same underlying issue - the subkeys being bound via SHA-1 signatures.

apologies if this is the wrong channel to report such issues, feel free to forward it or redirect me to a more appropriate venue!

[Noratrieb]

For more context, see rust-lang/rustup#3185 and its fixes https://blog.rust-lang.org/2023/02/01/Rustup-1.25.2.html, rust-lang/rustup#3186

[Fabian-Gruenbichler]

thanks for the context - maybe it is time to tackle this 1,5 years later, without the time pressure of needing to rollout a fix for failing validation in rustup? more and more software doing the validation will reject SHA-1 (at least by default, I know the policy is overridable)..

[RalfJung]

Cc @rust-lang/infra

[Mark-Simulacrum]

I'd expect rust-lang/rfcs#3724 to be the current trajectory of solving this, if I'm reading right that it would involve moving to new keys?

If it's just a matter of updating the signatures made, that would be something here - https://github.com/rust-lang/promote-release/blob/master/src/sign.rs, but at a cursory skim I think all the signatures there are over sha2-512.

Otherwise if there's a simpler key change that we could make (e.g. maybe we have some kind of intermediate? I'm not recalling the details of the key hierarchy...) we could consider that, but my guess is we wouldn't want to bother making changes since it's a lot of hassle. That said, the new PKI stuff has been a long time coming, and our current keys aren't great (e.g. not stored in HSMs and have been on multiple computers) so maybe we should move on a shorter timeframe.

[Fabian-Gruenbichler]

this is about the signing key itself - but you don't need to change the key (material/fingerprint) at all, this is just about the signatures within the public key (certificate). it's similar to adding a new UID to the key (which also requires a signature that is then stored in the public key/cert part of the key). the command I mention in my original post should fix this issue if run with access to the private key material, AFAIK.

FWIW, Debian (and I suspect other distros as well) doesn't support any other upstream tarball signature verification than OpenPGP (at least out of the box), so even if cargo and rustup switch to TUF at some point, it would still be great if the source release tarball continues to be signed with OpenPGP (as well). debcargo (which fetches crates from crates.io for packaging purposes) can easily switch to TUF, since it uses cargo under the hood anyway.

[lynxis]

Any news on replacing the sha1 part of the signing key?