Why import GPG key during dnf upgrade

Dear all,

I have upgraded from F33 to F34 recently (using the software app).
Today, I wanted to update the system (already being on F34!) using sudo dnf upgrade and I got the following message:

warning: /var/cache/dnf/updates-1eb77e9f45b4391a/packages/kernel-5.11.20-300.fc34.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
Fedora 34 - x86_64 - Updates                                                          1.6 MB/s | 1.6 kB     00:00    
Importing GPG key 0x45719A39:
 Userid     : "Fedora (34) <fedora-34-primary@fedoraproject.org>"
 Fingerprint: 8C5B A699 0BDB 26E1 9F2A 1A80 1161 AE69 4571 9A39
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64
Is this ok [y/N]: 

Why does the system need to import a new GPG key, and what does the NOKEY warning mean?

Also, maybe helpful: running $ curl https://getfedora.org/static/fedora.gpg | gpg --import yields the following output:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 12543  100 12543    0     0  48242      0 --:--:-- --:--:-- --:--:-- 48242
gpg: key 1161AE6945719A39: "Fedora (34) <fedora-34-primary@fedoraproject.org>" not changed
gpg: key 49FD77499570FF31: "Fedora (33) <fedora-33-primary@fedoraproject.org>" not changed
gpg: key 6C13026D12C944D0: "Fedora (32) <fedora-32-primary@fedoraproject.org>" not changed
gpg: key 50CB390B3C3359C4: "Fedora (31) <fedora-31-primary@fedoraproject.org>" not changed
gpg: key 7BB90722DBBDCF7C: "Fedora (iot 2019) <fedora-iot-2019@fedoraproject.org>" not changed
gpg: key 21EA45AB2F86D6A1: "Fedora EPEL (8) <epel@fedoraproject.org>" not changed
gpg: key 6A2FAEA2352C64E5: "Fedora EPEL (7) <epel@fedoraproject.org>" not changed
gpg: key 3B49DF2A0608B895: "EPEL (6) <epel@fedoraproject.org>" not changed
gpg: Total number processed: 8
gpg:              unchanged: 8
1 Like

Hi there. This is because of security reasons.
Every new release has its own new key.

Have a look here:

Scroll down, there are the finger prints, like:

Fedora 34

id:

4096R/45719A39 2020-08-06

Fingerprint:

8C5B A699 0BDB 26E1 9F2A 1A80 1161 AE69 4571 9A39

Your message probably means that the new fingerprint was not yet stored in the rpm data base.

In the first step you download the new files, by dnf system-upgrade download --releasever=34
With the second step you actually install the new version, by dnf system-upgrade clean.

I’m not sure when exactly the finger print is being checked. Could also be done by refreshing the repo the first time.

Edit
The Finger Print can be found in the dnf.logs under
/var/log/dnf.log*

Mine says, the new GPG has been added right after the new fedora 34 files has been downloaded (first step) and before dnf system-upgrade clean has been executed.

Does this information help?

To your second output, this probably means, that your keys are already installed in the gpg keyring and did not change. This did not happen for me. I didn’t had the fedora 34 finger print in the gpg keyring after upgrading and updating. You may have added it manually.
So you Public GPG Key of Fedora 34 already was imported.

Basically there is a public and a private part of the signature.
The finger print should be a hash of the public part.

Most interesting part, regarding your question might be:

Using public key fingerprints for key authentication

Further information: key authentication

When a public key is received over an untrusted channel, such as the Internet, the recipient often wishes to authenticate the public key. Fingerprints can help accomplish this, since their small size allows them to be passed over trusted channels where public keys won’t easily fit.

For example, if Alice wishes to authenticate a public key as belonging to Bob, she can contact Bob over the phone or in person and ask him to read his fingerprint to her, or give her a scrap of paper with the fingerprint written down. Alice can then check that this trusted fingerprint matches the fingerprint of the public key. Exchanging and comparing values like this is much easier if the values are short fingerprints instead of long public keys.

Fingerprints can also be useful when automating the exchange or storage of key authentication data. For example, if key authentication data needs to be transmitted through a protocol or stored in a database where the size of a full public key is a problem, then exchanging or storing fingerprints may be a more viable solution.

In addition, fingerprints can be queried with search engines in order to ensure that the public key that a user just downloaded can be seen by third party search engines. If the search engine returns hits referencing the fingerprint linked to the proper site(s), one can feel more confident that the key is not being injected by an attacker, such as a Man-in-the-middle attack.

PGP developed the PGP word list to facilitate the exchange of public key fingerprints over voice channels.

Since you said that you got your request for the new key long after the upgrade, it might be advised to double check integrity. Would it have been possible to upgrade to Fedora 34 without accepting the key? You may have accidentally chosen “No” in the process? Not sure if I’d look for my tinfoil hat in such a situation. :-/

However I think the new public key is not necessarily added to the gpg keyring during the upgrade process.

I’d check the logs.
grep -r "8C5B A699 0BDB" /var/log/dnf.*
To find the corresponding log and the go in and search for “8C5B”.

Dnf/yum use their own key space

This is not the same place then the gpg keyring. They use their own places and infrastructure, commands like rpm --import and rpm -qa gpg-pubkey*
Its key locations stored in the repo files. The finger prints are stored in the rpm database.

4 Likes

Hi, thanks for the thorough answer!

Have a look here:
Security and Download Verification
Scroll down, there are the finger prints, like:

Thanks for the link! I feel terribly stupid because I was looking at this page myself, but did not scroll down (where the fingerprints are indicated and it matches indeed with the one shown in my command line).

Since you said that you got your request for the new key long after the upgrade, it might be advised to double check integrity. >Would it have been possible to upgrade to Fedora 34 without accepting the key? You may have accidentally chosen “No” in the process? Not sure if I’d look for my tinfoil hat in such a situation. :-/

Maybe stupid me but I don’t know if the last sentence is sarcasm or not. Anyway, the request for the new key did not come ‘long’ after the upgrade from 33 to 34 but some days later when wanting to update the system (via sudo dnf upgrade).

However I think the new public key is not necessarily added to the gpg keyring during the upgrade process.

Yes I think that may be the origin of why I was confused, that and the fact that curl https://getfedora.org/static/fedora.gpg | gpg --import did not change or update any keys. However, as mentioned in your last link, gpg and dnf use different keyrings.

1 Like

Glad to hear. :slight_smile:

Sorry, this was not pointed at you, this was plain self irony.
I just know that this could have - maybe eventually already had - raised my personal mistrust in a similar situation and I eventually might have considered a fresh install. :sweat_smile:

1 Like

Ah right, haha, we’ve all been there! :wink: thank you for helping out!

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.