-
Notifications
You must be signed in to change notification settings - Fork 413
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release signing key still uses SHA1 #7124
Comments
Is there any guide on how to update my key to use SHA-256? |
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 :) |
Ah true.
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 |
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 |
Ouch :( I did this operation some time ago, but without |
Okay, I think I've regenerated the key by changing the expiration date instead. |
Which keyserver? I still see the old one. |
ldap://keyserver.pgp.com and hkps://keys.openpgp.org |
I still get this:
I didn't get anything newer from hkps://keys.openpgp.org |
And now? |
|
This is what I did about 10 minutes ago:
|
What |
I see:
|
ah, I know - keys.openpgp.org does not share UserID records (so, binding signatures too) unless you confirm your email address there |
But, getting from the other keyserver looks good now :) |
The new binding signature has current creation timestamp, so |
For what it is worth, you could use |
@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. |
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:
Steps to Reproduce
Expected behavior
Correct signature, with key not using SHA1 anymore.
The text was updated successfully, but these errors were encountered: