fwupd
Release signing key still uses SHA1
Describe the bug
The key used to sign release tarballs and git tags still uses SHA1 for its self-signature. Is updated key somewhere already?
SHA1 is starting to be rejected by some tools already, for example sequoia-sq:
$ sq inspect hughsie.pub
hughsie.pub: OpenPGP Certificate.
Fingerprint: 163EB50119225DB3DF8F49EA17ACBA8DFA970E17
Invalid: No binding signature at time 2024-04-17T13:46:39Z
Public-key algo: RSA
Public-key size: 2048 bits
Creation time: 2008-05-17 12:45:36 UTC
UserID: Richard Hughes <[email protected]>
Invalid: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
because: SHA1 is not considered secure
User attribute: UserAttribute { value (bytes): 4057 }
Invalid: Policy rejected non-revocation signature (PositiveCertification) requiring collision resistance
because: SHA1 is not considered secure
Steps to Reproduce
$ sqv --keyring hughsie.pub fwupd-1.8.14.tar.xz.asc fwupd-1.8.14.tar.xz
Signing key on 163EB50119225DB3DF8F49EA17ACBA8DFA970E17 is not bound:
No binding signature at time 2023-03-31T10:53:03Z
because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
because: SHA1 is not considered secure since 2023-02-01T00:00:00Z
Expected behavior
Correct signature, with key not using SHA1 anymore.
For example change its expiration date back and forth: https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel (scroll to "GnuPG 2.x" section)
Something I think worth asking; why generate the tar.xz and the detached signature in the first place? Github will generate a .zip and .tar.gz for you when you tag.
It's one less thing to worry about compromise at release time if you didn't do a separate tarball and detached signature.
The tag is signed with the same key, so the issue still stands.
But, as for "Github will generate a .zip and .tar.gz" - it indeed will. But those are generated dynamically (they will change when github changes some of its internal software) which is an issue if you care about reproducibility. But also those are not signed, so you can't verify their integrity after you download - which is a problem for any kind of tarball storage, offline build environment, caching services etc. Anyway, it's getting offtopic :)
The tag is signed with the same key, so the issue still stands.
Ah true.
But also those are not signed, so you can't verify their integrity after you download - which is a problem for any kind of tarball storage, offline build environment, caching services etc. Anyway, it's getting offtopic :)
Yeah sorry about straying off topic. Just thought it was a good opportunity to evaluate if it's wasted effort to be doing this separate signing at RELEASE time if there is already signed tags in use.
So, I followed all the instructions on howto regenerate the key and I just get gpg: make_keysig_packet failed: Time conflict -- the entire GPG UX is terrible.
I'm also wondering if we can just use https://github.com/fwupd/fwupd/archive/refs/tags/1.9.16.tar.gz -- and then maybe upload a sha256 hash of that, and a detached signature perhaps -- but maybe we don't need to do that either:
I'm also wondering if we can just use https://github.com/fwupd/fwupd/archive/refs/tags/1.9.16.tar.gz -- and then maybe upload a sha256 hash of that, and a detached signature perhaps -- but maybe we don't need to do that either:
Yes exactly
So, I followed all the instructions on howto regenerate the key and I just get
gpg: make_keysig_packet failed: Time conflict-- the entire GPG UX is terrible.
Ouch :( I did this operation some time ago, but without --faked-system-time and it worked. But that won't be nice for already existing signatures (IIUC they will be considered invalid by sequoia, not sure about GnuPG).
Okay, I think I've regenerated the key by changing the expiration date instead. sq inspect seems happy so I pushed the new key to the keyserver.
I still get this:
$ cat key | sq inspect --cetifications
Fingerprint: 163EB50119225DB3DF8F49EA17ACBA8DFA970E17
Invalid: No binding signature at time 2024-04-18T01:38:56Z
Public-key algo: RSA
Public-key size: 2048 bits
Creation time: 2008-05-17 12:45:36 UTC
UserID: Richard Hughes <[email protected]>
Invalid: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
because: SHA1 is not considered secure
Certification: Creation time: 2016-08-25 07:35:53 UTC
Alleged certifier: 23451B107AA03941
Hash algorithm: SHA256
Certification: Creation time: 2011-05-15 18:23:31 UTC
Alleged certifier: 5094FA7BA1C5B6A4
Hash algorithm: SHA1
Certification is not valid according to the current policy:
Policy rejected non-revocation signature (PositiveCertification) requiring collision resistance
Note: Certifications have NOT been verified!
User attribute: UserAttribute { value (bytes): 4057 }
Invalid: Policy rejected non-revocation signature (PositiveCertification) requiring collision resistance
because: SHA1 is not considered secure
Certification: Creation time: 2016-08-25 07:35:56 UTC
Alleged certifier: 23451B107AA03941
Hash algorithm: SHA256
Certification: Creation time: 2011-05-15 18:23:31 UTC
Alleged certifier: 5094FA7BA1C5B6A4
Hash algorithm: SHA1
Certification is not valid according to the current policy:
Policy rejected non-revocation signature (PositiveCertification) requiring collision resistance
Note: Certifications have NOT been verified!
I didn't get anything newer from hkps://keys.openpgp.org
$ gpg --keyserver hkps://keys.openpgp.org --recv-key 163EB50119225DB3DF8F49EA17ACBA8DFA970E17
gpg: key 17ACBA8DFA970E17: "Richard Hughes <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
This is what I did about 10 minutes ago:
$ gpg --send-keys 17ACBA8DFA970E17
gpg: sending key 17ACBA8DFA970E17 to hkps://keys.openpgp.org
What gpg --export 163EB50119225DB3DF8F49EA17ACBA8DFA970E17| sq inspect says on your side?
I see:
-: OpenPGP Certificate.
Fingerprint: 163EB50119225DB3DF8F49EA17ACBA8DFA970E17
Public-key algo: RSA
Public-key size: 2048 bits
Creation time: 2008-05-17 12:45:36 UTC
Expiration time: 2054-04-17 11:00:00 UTC (creation time + 45years 10months 30days 6h 38m 24s)
Key flags: certification, signing, authentication, transport encryption, data-at-rest encryption
UserID: Richard Hughes <[email protected]>
User attribute: UserAttribute { value (bytes): 3751 }
User attribute: UserAttribute { value (bytes): 4057 }
ah, I know - keys.openpgp.org does not share UserID records (so, binding signatures too) unless you confirm your email address there
The new binding signature has current creation timestamp, so sqv doesn't consider it for past releases (it looks for binding signature valid at the signing time), but it should be good for future releases.
Is there any guide on how to update my key to use SHA-256?
For what it is worth, you could use gpg --export-secret-key FINGERPRINT | sq cert lint --fix | gpg --import. Unfortunately, that doesn't yet work if your key is on a smartcard.
For example change its expiration date back and forth: https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel (scroll to "GnuPG 2.x" section)
@marmarek: That blog post has a number of errors. I reported them to the author, and they basically told me they won't fix them.