Rust release signing key uses SHA1 self-/binding signatures

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!

Start by reviewing the reported Rust release signing certificate and reproduce the issue with sq cert lint on the upstream rustc source archive key. Determine how the release signing key and its private key material are managed. Done means the relevant self- and binding signatures no longer rely on SHA-1 and the certificate passes the standard Sequoia policy.