5

My Fedora 26 system still has rpmkeys installed from Fedora 25 and RPMFusion for Fedora 25:

$ rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"
fdb19c98-56fd6333 gpg(Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>)
7fac5991-4615767f gpg(Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>)
64dab85d-57d33e22 gpg(Fedora 26 Primary (26) <fedora-26-primary@fedoraproject.org>)
fa7a179a-562bcd6e gpg(RPM Fusion nonfree repository for Fedora (25) <rpmfusion-buildsys@lists.rpmfusion.org>)
6806a9cb-562bce39 gpg(RPM Fusion free repository for Fedora (25) <rpmfusion-buildsys@lists.rpmfusion.org>)
d38b4796-570c8cd3 gpg(Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>)
  1. Does the recommended Fedora update process remove out of date Fedora GPG keys? I.e. is it at least expected to remove the key for Fedora 24, which is now past "end of life", if I've upgraded F24 -> F25 -> F26 ?
  2. Is there a documented process for removing out of date RPMFusion GPG keys?
  3. Rotating keys in this way seems like a good practice. (Revoking a compromised key would be another matter...) So retaining outdated keys on an upgraded system would not gain any of the benefits of Fedora rotating their keys. In case the answer to either of the above is "no", I guess I'd like to know if there are any less obvious implications of retaining outdated keys.
  • I haven't been able to come up with a good reason to remove old keys. I would like to hear of one. – Michael Hampton Apr 23 at 15:27
  • @MichaelHampton if there is no reason to remove old keys, then what reason is there to change keys in the first place? I think the reason is analagous to rotating passwords; it means that an evildoer who gains a key only does not have an unlimited amount of time to exploit that key. I do not aim to promote this practice; I am not aiming to stick to it myself. I just wanted to understand what's going on here. – sourcejedi Apr 23 at 15:34
  • Yes, every new Fedora release gets a new signing key. One thing that occurred to me, though, is that not every package gets upgraded. If a package is obsoleted then it'll just hang around on the upgraded system forever, until someone uninstalls it. That obsolete package was signed by an old key. If it's ever necessary to replace/reinstall the old package, you'd need to have that old key around to verify it. – Michael Hampton Apr 23 at 15:35
  • @MichaelHampton that seems fairly obscure, you would still need to find the package file somewhere – sourcejedi Apr 23 at 15:41
  • Not really, dnf can do that for you dnf --releasever=27 reinstall <package> but it'll fail if the old GPG key isn't available. – Michael Hampton Apr 23 at 15:42
1
  1. Not that I can tell from looking at any of the official documentation (though I may have missed something), but given that most users never touch the keys, I would assume it does (or at least that it's smart enough to remove keys which it knows are revoked).
  2. I would assume there is some 'official' procedure, but with some cursory searching I've not been able to find it (you can in theory always manipulate the GPG keyring directly without going through RPM, but I don't know whether or not that might break anything).
  3. Other than what you've outlined, I can't think of any negative implications to retaining the keys, but there is a very important reason to retain the most recent keys at least initially: If the update fails part way through and you have to roll back, you need the old keys.
  • Re 2): RPM does have documented features for inspecting and removing keys. blog.laimbock.com/2014/05/02/… I think my main question is whether RPM Fusion somehow manages to get out-dated keys automatically removed, presumably when rpmfusion-release is upgraded. Like you say for the main fedora repos, the issue is not explicitly mentioned in the docs. I notice the official Fedora upgrade instructions do not require disabling third-party repos first, and do explicitly mention such repos. fedoraproject.org/wiki/Upgrading – sourcejedi Oct 26 '17 at 22:16
0

dnf system-upgrade is almost disturbingly simple. It doesn't have any special handling of keys. The package which contains the Fedora keys also seems quite simple and not to be hiding any special handling of keys. Therefore I expect that dnf system-upgrade prompts to accept the new key, because that's what dnf usually does, but it never results in any key being removed.

EDIT: By now, I have upgraded Fedora from 26 -> 27 -> 28, and the Fedora 25 key was still retained.

If you want to work around this, the best opportunity is just before a distribution upgrade. You can remove all your rpmkeys and start afresh with rpm -e --allmatches gpg-pubkey-*-*. This is relatively safe; rpmkeys can always be re-installed if necessary. Fedora keeps all its rpmkeys available in /etc/pki/rpm-gpg/, including all the old ones.

Some third-party repo configs, such as Google's, would have to re-download missing rpmkeys over HTTPS. I.e. authenticated by the hole-y Web PKI. This looks somewhat sub-optimal. I kind of doubt it implements certificate pinning.

The GNOME Software / PackageKit route is a little more obscure. When you use PackageKit instead of dnf, my understanding is that PackageKit uses its own trust mechanism in place of RPM's. This mechanism looks like it will ignore the old keys immediately after a distribution upgrade.

Strangely, it looks like PackageKit even stores the third-party keys under a directory based on the version of Fedora (/var/cache/PackageKit/28/metadata/google-chrome/...). This suggests that PackageKit will re-download keys like Google's over HTTPS anyway. So if you use any GUI based on PackageKit, it's hard to do anything about that.

Debian contrasts with Fedora here. I'm sure I've seen Debian remove old Debian keys (maybe in part when I looked at the history of files in my etckeeper). I haven't looked into PackageKit on Debian. As far as I know, apt does not have the "feature" that dnf does to download missing third-party signing keys over HTTPS.

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.