Tim via users wrote:
>> If you remove the key and run dnf again, it should prompt
>> you to install the current key, which will (hopefully) work.
>>
>> In other words:
>>
>> $ sudo rpm -e gpg-pubkey-17280ddf
>
> I've encountered that kind of thing before, but why does it require
> manual intervention? Surely there should be some mechanism for key
> revocation and replacement?
There is not, AFAIK, an automated way to do that with
dnf/rpm. It would be handy, there's no doubt.
At the same time, doing that sort of thing securely and
automatically is harder than it seems at first glance, so I
suspect that's one of the various reasons it's not been done
yet.
It could useful if there was a way to mark a key as
obsoleted by another and have rpm process that like it does
with general package dependencies, perhaps. But that also
opens up a lot of ways to screw things up. :)
To be accurate, there is to some extent, but not when the
key is updated in place, as was apparently the case here.
That's why manual intervention was required. More on that
toward the end.
It was only recently (F38 or F39 time frame, IIRC), that the
custom PGP handling code in rpm was replaced with the more
modern Sequoia implementation. That may offer some better
methods to handle these sort of things. And I imagine the
upstream rpm (and/or dnf) folks would welcome patches.
The older PGP implementation in rpm was more forgiving of
old keys, weak keys, and such. That meant that this sort of
thing came up less often (for better and worse). Maybe the
move to Sequoia will help improve that by calling out the
lack of a cleaner way to rotate old/weak keys.
Now, as to how a new key can be rolled out with minimal
interruption to users, there is a relatively clean way to
handle this.
The first step is to add a new key to the gpgkey parameter
in the yum repo file, e.g.:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-foo-new
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-foo
After that is pushed out, packages can be signed by the new
key and systems will pick it up automatically. Users who
have modified their yum repo file won't get this change
automatically (presuming it's provided via an rpm update to
a foo-release package, that is -- unless the repo file isn't
marked as a config, but that has other downsides...).
Also, the old key will be left in the rpm database, which is
a downside that would be nice to correct. It can be removed
from the yum repo file after the transition though, to
avoid new systems from pulling it in needlessly.
(In theory, a foo-release package could provide a cron job or
something which called rpm -e to remove the old key, but I'm
not sure I'd want packages doing that themselves.)
None of that is to say I like the status quo. But I also
can't supply patches to correct it. All I can do is help
deal with things like this when I run across them. :)
--
Todd
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
