-
Notifications
You must be signed in to change notification settings - Fork 17
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
Microsoft (Release signing) GPG key uses SHA-1 signature #47
Comments
Thank you for filling this issue @neverpanic, You're right that this definitely sounds like something we should be fixing according to policy. I'll raise the issue internally with our security team. |
maybe consider using different gpg keys for the OSes/major versions ( see #32 ) that way you can easily use a new key every major release and you don't have to worry about backwards compatibility the key |
While you're at it, email to the Microsoft email shown in the above gpg dump (User ID - Microsoft (Release signing) gpgsecurity@microsoft.com) is invalid. I tried sending an email there yesterday, and it bounced. `` Delivery to the following recipients failed permanently: .. Reason: Permanent Error |
@neverpanic We are testing out an update internally but have run into an issue. Even if you generate a new pub key that uses SHA2 hashing algos from the existing private key, that pub key cannot be used to verify rpms that have been previously signed by this key. The new pub key would import into F38 just fine, but not verify old packages. And vice-versa, newly-signed RPMs would not verify with the old pub key. This seems to be because the RPM headers store the pub key's id that they were signed with, and This is very impactful for us, because many of the repos Microsoft publishes are platform-agnostic, like Or alternately I suppose we could go back and re-sign every one of these agnostic rpms and exclusively use the new pub key everywhere, but that seems undesirable also. Is there some better solution that I'm missing? |
I think you need to go a step further if you want to make this future proof -- a key/repo per os+major version, that's how fedora (https://getfedora.org/security/) operates, also rhel/alma/..., epel They have different keys/repositories for every major release. |
RPM in Fedora 38 uses Sequoia PGP. Sequoia only considers a signature valid if at the time the signature was made, a valid binding signature connecting your signing key to your key identity was available. My guess is this isn't the case for you, because you re-signed your previous key, which replaced the signature time with the current date. If you want packages that were previously signed to continue to work, just must either backdate the new binding signatures on your keys (e.g., by running gpg under libfaketime) or by using a tool that will not modify the original timestamps.
You could use the same public key and re-sign all of the RPMs, although I do understand that may be a bit annoying. |
Describe the issue
The GPG key used to sign packages for Fedora uses a Positive certification of a User ID and Public Key packet with a SHA-1 signature. Due to recent attacks on SHA-1 Fedora is working to deprecate and disable signatures made with SHA-1 by default, which affects your key. See rhbz#2170878 for more details. Specifically, see comment 61 for a description of the user experience when installing Microsoft Edge on Fedora 38.
When did the issue occur?
Occurs on Fedora 38 at any point in time.
If applicable, what package did you attempt to install, and from which repo?
microsoft-edge-beta-111.0.1661.24-1.x86_64.rpm
Steps to Reproduce
curl -sL https://packages.microsoft.com/keys/microsoft.asc | pgpdump -i
and check for "Hash alg - SHA1(hash 2)":Actual Result
SHA-1 is used in the "Positive certification of a User ID and Public Key packet" signature.
Expected Result
SHA-1 is not used in any signatures.
Additional context
Please see Microsoft's policy on SHA-1 signed content at https://learn.microsoft.com/en-us/lifecycle/announcements/sha-1-signed-content-retired
Please update your key to not use a SHA-1 signature. The sequoia project has a tool called sq-keyring-linter that can do this for you, see https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c26.
The text was updated successfully, but these errors were encountered: