GPG key for signing Firefox Releases
Hello, trying to verify the integrity of firefox-118.0.1.tar.bz2 I realized the GPG key has changed.
The following blog post details the change and shows the new key: https://blog.mozilla.org/security/2023/05/11/updated-gpg-key-for-signing-firefox-releases/
But when I download the key using the link provided (which points to keys.openpgp.org) the key I get is different from the key posted on the Mozilla blog page.
What is even more strange, is that the key from keys.openpgp.org declares in the comment that 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353 is the fingerprint of the key (the same that is posted on the Mozilla blog) but it can't be because the key different.
So my questions: 1) Why Mozilla is posting a link to a key that is different? 2) Why keys.openpgp.org shows the correct fingerprint with a different key?
And, in the end, which key should I trust and why.
Thanks.
被選擇的解決方法
Visual inspection of a "PGP PUBLIC KEY BLOCK" is not reliable, it contains more than just the public key and it does not all need to match. If you compare the fingerprints by opening them with the gpg command, you will see that they match.
從原來的回覆中察看解決方案 👍 0所有回覆 (5)
The keys are listed in https://archive.mozilla.org/pub/firefox/releases/118.0.1/
The PGP key can include various subkeys and signatures with different orders, the important thing is that the fingerprint matches.
Thanks for your replies, I think the subject line I put on this post might have been misleading.
I am not asking where is the key. I know where it is. What I am saying is that there seems to be a mismatch between the key posted by Mozilla on the blog and the key referenced by Mozilla in other places (please see the attachment of my original post). For clarity's sake, I'm talking about the updated key, I'm not comparing the updated key with the old key.
Inspecting the two keys visually, between the BEGIN PGP PUBLIC KEY BLOCK and the END PGP PUBLIC KEY BLOCK, they look different.
One begins with mQINB.... and the other begins with xsFN....
As they are not the same, the fingerprint must also be different. The fact that in the comment field the fingerprint is the same in both keys seems to me even more suspicious, because they key is not made by the same bytes and so the fingerprints cannot be the same.
Hope this clarifies my question.
選擇的解決方法
Visual inspection of a "PGP PUBLIC KEY BLOCK" is not reliable, it contains more than just the public key and it does not all need to match. If you compare the fingerprints by opening them with the gpg command, you will see that they match.
You're right, the data inside the "PGP PUBLIC KEY BLOCK" does not contain only the public key.
I just found out that the first byte of a PGP packet is actually a tag. The problem is that this tag, which is encoded base64, is available in two formats, the old format and the new format.
That is the source of the apparent mismatch between two identical keys. So, if you calculate the fingerprint of the whole block the result will be different, but if you calculate it via GPG (which removes the tag) the fingerprints will be the same.
More information are available here
As a side note, PGP is already a user "unfriendly" technology for many people, and these kind of issues IMHO do not help in making it more usable and trustable.