Rust release signing key uses SHA1 self-/binding signatures #133638
Description
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!