search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
99.01k stars 12.79k forks source link

Rust release signing key uses SHA1 self-/binding signatures #133638

Open Fabian-Gruenbichler opened 6 hours ago

Fabian-Gruenbichler commented 6 hours ago

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 commented 5 hours ago

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

Fabian-Gruenbichler commented 1 hour ago

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)..