microsoft
Microsoft (Release signing) GPG key uses SHA-1 signature
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)":
$ curl -sL 'https://packages.microsoft.com/keys/microsoft.asc' | pgpdump -i
Old: Public Key Packet(tag 6)(269 bytes)
Ver 4 - new
Public key creation time - Thu Oct 29 00:21:48 CET 2015
Pub alg - RSA Encrypt or Sign(pub 1)
RSA n(2048 bits) - c0 2a 86 61 66 52 71 18 d1 96 ce a5 7e d4 e1 b5 c6 24 1e a2 8c 0a 86 cb 06 00 ab dd f9 bb 97 08 62 12 64 9c 13 2d 76 6a 21 c2 22 2c fe e9 a9 d7 19 5a d1 3d 6d 27 3b c8 16 36 31 a9 43 a7 d2 e2 bb 42 9e 93 2c 10 e9 55 57 d5 3e f6 34 f7 f9 12 fe b1 e8 32 d5 ed a5 56 b0 2c d4 00 5f 9e 6f b0 c2 f5 f3 ee 14 b1 1d c6 63 84 62 83 e3 ce b4 3b 70 29 d2 57 82 50 c4 0a a1 53 84 fa 3a 36 ef 45 ac c6 97 76 a0 39 e8 b3 3d 79 91 96 33 2d 51 4b 6d 1d 06 67 46 1b 65 ce 49 b0 22 b5 22 bd b7 c5 3c 3f 9f 12 81 c9 d7 eb 88 75 f3 b3 65 7f 3f a0 a1 ca 2d ed a3 1f ad f6 92 fb 0d cc 91 65 44 e5 6f 18 b6 00 93 65 91 70 bb be 46 38 e0 82 2c 61 c2 20 7e 32 ef c0 f1 37 f8 57 a6 fe 62 9a 52 e3 8a bc 12 f5 6b 33 e4 2f 63 b2 cd 48 e7 df 48 ee 92 96 cc bd a2 2b 06 4d d7 c4 df d9 c2 ee 95 51
RSA e(17 bits) - 01 00 01
Old: User ID Packet(tag 13)(55 bytes)
User ID - Microsoft (Release signing) <[email protected]>
Old: Signature Packet(tag 2)(309 bytes)
Ver 4 - new
Sig type - Positive certification of a User ID and Public Key packet(0x13).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Thu Oct 29 00:21:48 CET 2015
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
Sym alg - AES with 256-bit key(sym 9)
Sym alg - AES with 192-bit key(sym 8)
Sym alg - AES with 128-bit key(sym 7)
Sym alg - CAST5(sym 3)
Sym alg - Triple-DES(sym 2)
Hashed Sub: preferred hash algorithms(sub 21)(3 bytes)
Hash alg - SHA1(hash 2)
Hash alg - SHA256(hash 8)
Hash alg - RIPEMD160(hash 3)
Hashed Sub: preferred compression algorithms(sub 22)(2 bytes)
Comp alg - ZLIB <RFC1950>(comp 2)
Comp alg - ZIP <RFC1951>(comp 1)
Hashed Sub: features(sub 30)(1 bytes)
Flag - Modification detection (packets 18 and 19)
Hashed Sub: key server preferences(sub 23)(1 bytes)
Flag - No-modify
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xEB3E94ADBE1229CF
Hash left 2 bytes - 1a 9b
RSA m^d mod n(2047 bits) - 7d af 2b 2d bd 1e 0e 75 1f d7 5f 14 93 31 d3 f6 bf 17 ee 6f 29 e0 9e 56 a8 a6 bf 24 cc d3 80 be 5c 43 4d b9 26 d8 67 77 91 3c 71 87 14 ba 9e 30 d1 b1 b1 f6 fb 0b b6 71 11 e5 bb 27 fb d2 cd 18 07 c6 6e d9 bc 44 a2 b1 46 11 16 ad ac 82 42 7e 1c 51 11 36 ba 9f 72 2e 39 6d d8 66 ad 4b 32 ed 25 b0 f7 26 f1 74 53 a4 b9 0a 32 28 3d ed 06 68 86 7c e3 50 32 50 5a 38 c5 9d 02 c8 9c f7 ae 6b bc 9b 1d e7 36 1a 65 91 48 d5 4c 13 90 55 d5 28 9b 77 6e 9d cd 82 7d 6f 11 85 f0 8a 31 93 6b e1 57 cf a1 8b 1e e7 89 c0 5d 08 ee e8 37 e0 38 14 90 01 6f 02 cf 07 69 ca f6 0d 16 31 2f 94 49 5d d3 60 8f 82 5d db f8 3a 4f d2 27 99 64 f4 84 04 a5 8e ea fe 74 99 f3 36 23 42 91 b9 fd 29 b5 fb 27 fa 8a d4 86 d1 f3 2e 7a d3 24 66 16 c5 3e 35 d0 85 4d 6e f0 63 41 5b d5 f5 89 fb f2 93 b0 2e
-> PKCS-1
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.
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
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.
While you're at it, email to the Microsoft email shown in the above gpg dump (User ID - Microsoft (Release signing) [email protected]) is invalid.
I tried sending an email there yesterday, and it bounced.
`` This is an automatically generated Delivery Status Notification.
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 rpmkeys just doesn't recognize the new pub key as a valid option for verifying the signature.
This is very impactful for us, because many of the repos Microsoft publishes are platform-agnostic, like edge, as you initially pointed out, or azure-cli. These are self-contained packages that can be installed on any basically any rpm-based distro. Except not now, because there's no way to sign them with a single key that all distros will accept. We'd have to sign a given binary twice, and make one available in an "old distros" repo and the other available in a "new distros" repo.
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?
We'd have to sign a given binary twice, and make one available in an "old distros" repo and the other available in a "new distros" repo.
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.
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
rpmkeysjust doesn't recognize the new pub key as a valid option for verifying the signature.
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.
sq-keyring-linter is such a tool, but will only work for you if your private key is exportable, i.e., not in an HSM.
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?
You could use the same public key and re-sign all of the RPMs, although I do understand that may be a bit annoying.