primeos-work
commented
6 days ago Update: I just discovered https://github.com/rpm-software-management/dnf5/issues/1192 so it looks like there's hope on the horizon.
I guess we could consider closing this issue then, given that https://github.com/fedora-copr/copr apparently also doesn't rotate the keys and that https://github.com/rpm-software-management/rpm/pull/3083 already got merged (apparently that PR alone isn't sufficient though: https://github.com/rpm-software-management/dnf5/issues/1192#issuecomment-2149499080).
That said, all (perhaps with some exceptions for rolling releases, etc.?) current RPM based distributions are still affected by this and will likely remain affected for their lifetime (so LTS users remain affected until their distro hits EOL and they upgrade to a newer LTS release).
The updated key expires 2026-12-29:
$ curl -sL https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key | gpg --show-key
pub rsa2048 2022-08-25 [SC] [expires: 2026-12-29]
DE15B14486CD377B9E876E1A234654DA9A296436
uid isv:kubernetes OBS Project <isv:kubernetes@build.opensuse.org>
jan-kolarik
I also ran into #3818 but on Fedora 40. The additional issue here is that updating
gpgkeyin/etc/yum.repos.d/kubernetes.repoisn't enough here as the Package manager (dnf) has already downloaded the key and, at least in my case, will not try to re-fetch it (even if I disable the repo, rundnf clean all, and enable it again). I didn't have such issues with other repos and the problem here seems to be that only the expiration date of the key was extended instead of rotating the entire key. I'm not adnfexpert but I think most repos are switching to new keys instead of extending the experiation date. AFAIK it should also be possible to fetch/import multiple keys from a single URL so that should help with supporting older and newer packages (in this case only relevant when using an olderbaseurlwith a newergpgkeyURL).What happened:
I updated the repository:
And I can fetch the current version of the key from the
gpgkeyURL:But updating still fails:
Workarounds:
I can use the following manual workaround to remove the key so that
dnfwill have to import it again:There should be other workarounds available but this is the easiest one I came up with as there doesn't seem to be a good
dnfcommand for it yet.What you expected to happen:
dnf updatewill prompt to (re)import/update the key. This doesn't seem possible so the repo key should be rotated entirely instead of only extending the expiration date.How to reproduce it (as minimally and precisely as possible):
Install from an older repository with the expired key and then try to update again.
Version 1.27 seems to be the most recent version that offers the old key:
I can provide the exact commands if necessary but the basic steps are the following:
rpm -qa | grep 9a296436 | xargs rpm --erase/etc/yum.repos.d/kubernetes.repoback to version 1.27 (or an older version)kubectl) from the old repo. You might have to disablegpgcheck. Interestingly the expired key erros seem to be ignored when downgrading via:dnf downgrade kubectl/etc/yum.repos.d/kubernetes.repoback to the most recent version (currently 1.31)dnf upgrade kubectl-> it will fail due to the expired keyAnything else we need to know?:
Environment:
Fedora 40 but it should apply to any
yum/dnfbased system (it might work better with the futurednf5though - I didn't look at that).