Release signing key still uses SHA1

[marmarek]

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 <richard@hughsie.com>
                 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.

[hughsie]

Is there any guide on how to update my key to use SHA-256?

[marmarek]

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)

[superm1]

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.

[marmarek]

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

[superm1]

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.

[hughsie]

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.

[hughsie]

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:

[superm1]

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

[marmarek]

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

[hughsie]

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.

[marmarek]

Which keyserver? I still see the old one.

[hughsie]

Which keyserver

ldap://keyserver.pgp.com and hkps://keys.openpgp.org

[marmarek]

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 <richard@hughsie.com>
                 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

[hughsie]

I didn't get anything newer from hkps://keys.openpgp.org

And now?

[marmarek]

$ gpg --keyserver hkps://keys.openpgp.org  --recv-key 163EB50119225DB3DF8F49EA17ACBA8DFA970E17
gpg: key 17ACBA8DFA970E17: "Richard Hughes <richard@hughsie.com>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

[hughsie]

This is what I did about 10 minutes ago:

$ gpg --send-keys 17ACBA8DFA970E17
gpg: sending key 17ACBA8DFA970E17 to hkps://keys.openpgp.org

[marmarek]

What gpg --export 163EB50119225DB3DF8F49EA17ACBA8DFA970E17| sq inspect says on your side?

[hughsie]

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 <richard@hughsie.com>

	 User attribute: UserAttribute { value (bytes): 3751 }

	 User attribute: UserAttribute { value (bytes): 4057 }

[marmarek]

ah, I know - keys.openpgp.org does not share UserID records (so, binding signatures too) unless you confirm your email address there

[marmarek]

But, getting from the other keyserver looks good now :)

[marmarek]

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.

[nwalfield]

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.

[nwalfield]

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.