I have downloaded the Fedora-33 KDE spin and am attempting to verify it. Following the instructions (appended below for convenience) I have: * Imported the keys using curl (where do they go?) and * Verified the CHECKSUM file using gpg
The verification fails with this message: $ gpg --verify-files *-CHECKSUM gpg: Signature made Fri 23 Oct 2020 08:09:07 AM PDT gpg: using RSA key 963A2BEB02009608FE67EA4249FD77499570FF31 gpg: Good signature from "Fedora (33) fedora-33-primary@fedoraproject.org" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 963A 2BEB 0200 9608 FE67 EA42 49FD 7749 9570 FF31 This doesn't look good. How can I verify the CHECKSUM file?
Verification instructions from https://spins.fedoraproject.org/en/verify%C2%A0follow: Next, import Fedora's GPG key(s): $ curl https://getfedora.org/static/fedora.gpg | gpg --import You can verify the details of the GPG key(s) here. Now, verify that the CHECKSUM file is valid: $ gpg --verify-files *-CHECKSUM The CHECKSUM file should have a good signature from one of the following keys: - 12C944D0 - Fedora 32 - 3C3359C4 - Fedora 31 - CFC659B9 - Fedora 30 - DBBDCF7C - IOT 2019 Finally, now that the CHECKSUM file has been verified, check that the image's checksum matches: $ sha256sum -c *-CHECKSUM If the output states that the file is valid, then it's ready to use!
On Thu, 11 Feb 2021 at 12:54, Jonathan Ryshpan jonrysh@pacbell.net wrote:
I have downloaded the Fedora-33 KDE spin and am attempting to verify it. Following the instructions (appended below for convenience) I have:
- Imported the keys using curl (where do they go?) and
- Verified the CHECKSUM file using gpg
The verification fails with this message: $ gpg --verify-files *-CHECKSUM gpg: Signature made Fri 23 Oct 2020 08:09:07 AM PDT gpg: using RSA key 963A2BEB02009608FE67EA4249FD77499570FF31 gpg: Good signature from "Fedora (33) fedora-33-primary@fedoraproject.org" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 963A 2BEB 0200 9608 FE67 EA42 49FD 7749 9570 FF31 This doesn't look good. How can I verify the CHECKSUM file?
Check the fingerprint against fingerprints of Fedora current keys at the bottom of the https://getfedora.org/security/ page. Fedora 33 id: 4096R/9570FF31 2020-01-28 Fingerprint: 963A 2BEB 0200 9608 FE67 EA42 49FD 7749 9570 FF31
*Verification instructions from https://spins.fedoraproject.org/en/verify https://spins.fedoraproject.org/en/verify follow:* Next, import Fedora's GPG key(s):
$ curl https://getfedora.org/static/fedora.gpg | gpg --import
You can verify the details of the GPG key(s) here https://getfedora.org/en/security. Now, verify that the CHECKSUM file is valid:
$ gpg --verify-files *-CHECKSUM
The CHECKSUM file should have a good signature from one of the following keys:
- 12C944D0 - Fedora 32
- 3C3359C4 - Fedora 31
- CFC659B9 - Fedora 30
- DBBDCF7C - IOT 2019
Finally, now that the CHECKSUM file has been verified, check that the image's checksum matches:
$ sha256sum -c *-CHECKSUM
If the output states that the file is valid, then it's ready to use!
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Feb 11, 2021 at 08:52:51AM -0800, Jonathan Ryshpan wrote:
The verification fails with this message: $ gpg --verify-files *-CHECKSUM gpg: Signature made Fri 23 Oct 2020 08:09:07 AM PDT gpg: using RSA key 963A2BEB02009608FE67EA4249FD77499570FF31 gpg: Good signature from "Fedora (33) fedora-33-primary@fedoraproject.org" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 963A 2BEB 0200 9608 FE67 EA42 49FD 7749 9570 FF31 This doesn't look good. How can I verify the CHECKSUM file?
GPG's concept of trust is ... well-meaning, but not user friendly. You can trust the key you just imported because you just downloaded it from the official Fedora website via https. GPG, however, does not know that. So, it gives this error. You can use the `gpg --edit-key` command to tell it to trust this key, if you wanto to not get that warning.
On Thu, 11 Feb 2021 at 15:31, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Feb 11, 2021 at 08:52:51AM -0800, Jonathan Ryshpan wrote:
The verification fails with this message: $ gpg --verify-files *-CHECKSUM gpg: Signature made Fri 23 Oct 2020 08:09:07 AM PDT gpg: using RSA key 963A2BEB02009608FE67EA4249FD77499570FF31 gpg: Good signature from "Fedora (33) fedora-33-primary@fedoraproject.org" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 963A 2BEB 0200 9608 FE67 EA42 49FD 7749 9570 FF31 This doesn't look good. How can I verify the CHECKSUM file?
GPG's concept of trust is ... well-meaning, but not user friendly. You can trust the key you just imported because you just downloaded it from the official Fedora website via https. GPG, however, does not know that. So, it gives this error. You can use the `gpg --edit-key` command to tell it to trust this key, if you wanto to not get that warning.
You don't use the key that often, and there is the small possibility that a compromise is discovered and the key is no longer trusted. Being a bit more careful/paranoid, check that the signature still matches the current official Fedora website via https.
Matthew Miller wrote:
GPG's concept of trust is ... well-meaning, but not user friendly. You can trust the key you just imported because you just downloaded it from the official Fedora website via https. GPG, however, does not know that. So, it gives this error. You can use the `gpg --edit-key` command to tell it to trust this key, if you wanto to not get that warning.
It's a shame that gpgv doesn't support ascii-armored keyrings¹, or we could save a step and suggest:
$ curl -O https://getfedora.org/static/fedora.gpg $ gpgv --keyring ./fedora.gpg CHECKSUM
As it is, we'd need to either suggest de-armoring the keyring first or switch to provide a non-armored fedora gpg keyring on the website. Doing the latter would seem like an easy win in terms of making the verification steps simpler. And we could always keep the ascii-armored content as fedora.asc if we wanted.
I don't know why we name the keyring fedora.gpg and not fedora.asc since it's ascii-armored, to be honest.
(I contributed to the website code surrounding the verification steps many years ago, and I still don't recall why that's the case. It appears that I had the --armor option in the initial version of the update-gpg-keys script I contributed. That might have just been keeping the status-quo, as the fedora.gpg file existed prior to the script, it was simply managed much more manually.)
If fedora.gpg was not ascii-armored, the above gpgv command looks like this:
$ gpgv --keyring ./fedora.gpg Fedora-Spins-33-1.2-x86_64-CHECKSUM gpgv: Signature made Fri Oct 23 15:09:07 2020 UTC gpgv: using RSA key 963A2BEB02009608FE67EA4249FD77499570FF31 gpgv: Good signature from "Fedora (33) fedora-33-primary@fedoraproject.org"
Alternately, we _could_ suggest adding `--trust-model always` to the gpg command, though that still prints a warning:
$ gpg --trust-model always --verify-files Fedora-Spins-33-1.2-x86_64-CHECKSUM gpg: Signature made Fri Oct 23 15:09:07 2020 UTC gpg: using RSA key 963A2BEB02009608FE67EA4249FD77499570FF31 gpg: Good signature from "Fedora (33) fedora-33-primary@fedoraproject.org" [unknown] gpg: WARNING: Using untrusted key!
¹ https://dev.gnupg.org/T2290 has been around for years and was just lowered in priority yesterday -- in case anyone feels like submitting a patch. ;)
-
George N. White III -
Jonathan Ryshpan -
Matthew Miller -
Todd Zullinger