1

Fedora 24 pops up this lovely GUI-triggered update to Fedora 25 (using gnome-software). The instructions for upgrading Fedora workstation simply list the steps to click through in the GUI. Good job!

When I went to install some software, I was surprised to find this prompt/warning:

$ sudo dnf upgrade
...
warning: /var/cache/dnf/updates-1d34501737ae01ab/packages/NetworkManager-openconnect-1.2.4-3.fc25.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fdb19c98: NOKEY
Importing GPG key 0xFDB19C98:
 Userid     : "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>"
 Fingerprint: C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
Is this ok [y/N]:

Does this mean automatic updates (notifications) are silently failing unless I manually install something and accept the key??

1 Answer 1

4

Actually this is fine. I might even argue it is the best way to do it :-).

The automatic update notifications in Fedora Workstation use PackageKit. They do not use the dnf command.

You can see that pkcon installs packages successfully, (or updates with pkcon -c 1 refresh && pkcon update (explanation of -c here)). It does not prompt about the key. Nor does it install the key in the store used by dnf; if you run dnf again it will still prompt to accept the key.

This surprised me, because the keystore used by dnf is actually rpm. PackageKit acts as a frontend to rpm, but apparently it does not populate the rpm keyring or rely on it for verification.

You can see that PackageKit instead saves keys in e.g. /var/cache/PackageKit/25/metadata/fedora/gpgdir/. Arguably this makes more sense than the traditional organization. This way, it is possible to tell which keys have been downloaded for which repo.

Unlike dnf, PackageKit does not prompt to accept keys from the configured URL. (Note that if it did prompt to save this file in /var/cache, strictly speaking this file would not be a pure cache, as it would also represent user configuration :-).

The lack of prompting does not decrease the security of Fedora, because e.g. /etc/yum.repos.d/fedora.repo says to load the key from a file, which has already been installed (by the fedora-release package). The prompting by dnf would also be skipped if you used scripts with dnf -y install - this being the standard way to avoid prompting when the installed package has additional requirements. (The Ansible dnf module does the same thing).

I conclude this prompt by dnf is not considered to serve an important purpose. Considering the scenario in the question, it would probably be better to remove the prompt that says "warning", and asks "Is this ok". (And it would be best to fix libdnf to use the same pattern as PackageKit. From a security position it seems quite strange to keep old RPM keys around indefinitely.

EDIT: in newer versions, both PK and dnf are now implemented using libdnf. So there are even fewer excuses to not fix this :-).

Other repos like google-chrome.repo might rely on downloading updated keys over HTTPS. This has different security properties. In particular, it seems less likely that key pinning and HSTS (as used by the main HTTPS clients) have been implemented for PackageKit. I am unclear why this possibility was implemented in the first place, i.e. downloading updated keys using a method with different security properties. At minimum, it seems an argument for not keeping downloaded keys in /var/cache/, which the user may wish to clear when they have an urgent need of disk space.

4
  • FWIW, installing a package with the Ansible Dnf module from a newly added repository also doesn't add the repository's key to the dnf keyring such that one is confronted with the key-import-prompt on next dnf command line usage. Which baffled me a bit because it creates a kind of uncertainty regarding whether the gpg signatures were really being checked during the Ansible Dnf install execution ... Aug 14, 2020 at 14:37
  • @maxschlepzig thank you for giving me nightmares: docs.ansible.com/ansible/latest/modules/…
    – sourcejedi
    Aug 14, 2020 at 22:50
  • After observing this I turned to that doc and saw this disable_gpg_check option - first it calmed be down a bit because it's disabled by default and thus indicates that the Dnf module is indeed checking signatures - but then I thought: 'wait a minute, how is it able to check signatures when it isn't importing the GPG key ?!?...' - this triggered then some further searching which made me discover your posting here ... So perhaps it imports the key to some other location, as well. I guess I have to verify that ... Aug 15, 2020 at 7:30
  • @maxschlepzig Sorry! I shouldn't post late at night, I mis-read and thought "no" meant "no gpg checking".
    – sourcejedi
    Aug 15, 2020 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.