Greetings,
When updating via dnf update I get the following error messages: The GPG keys listed for the "Signal Messaging Devel Project (Fedora_40)" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository.. Failing package is: nodejs-electron-30.3.0-2.13.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep... Public key for signal-desktop-7.19.0-1.1.x86_64.rpm is not trusted. Failing package is: signal-desktop-7.19.0-1.1.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep... Public key for signal-libringrtc-2.45.0-1.1.x86_64.rpm is not trusted. Failing package is: signal-libringrtc-2.45.0-1.1.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep...
Any guidance here would be appreciated.
Thank you,
Max Pyziur pyz@brama.com
Max Pyziur wrote:
Greetings,
When updating via dnf update I get the following error messages: The GPG keys listed for the "Signal Messaging Devel Project (Fedora_40)" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository.. Failing package is: nodejs-electron-30.3.0-2.13.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep... Public key for signal-desktop-7.19.0-1.1.x86_64.rpm is not trusted. Failing package is: signal-desktop-7.19.0-1.1.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep... Public key for signal-libringrtc-2.45.0-1.1.x86_64.rpm is not trusted. Failing package is: signal-libringrtc-2.45.0-1.1.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep...
Any guidance here would be appreciated.
Those keys may be using an algorithm or have various properties which the newer rpm signature verification library doesn't like.
I don't know what the policies are for rpm with the sequoia library backend, so this could be way off.
Another possibility is that the keys have been updated since you initially installed them and you need to remove the current key to allow dnf to import the updated key.
I wrote:
Max Pyziur wrote:
Greetings,
When updating via dnf update I get the following error messages: The GPG keys listed for the "Signal Messaging Devel Project (Fedora_40)" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository.. Failing package is: nodejs-electron-30.3.0-2.13.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep... Public key for signal-desktop-7.19.0-1.1.x86_64.rpm is not trusted. Failing package is: signal-desktop-7.19.0-1.1.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep... Public key for signal-libringrtc-2.45.0-1.1.x86_64.rpm is not trusted. Failing package is: signal-libringrtc-2.45.0-1.1.x86_64 GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep...
Any guidance here would be appreciated.
[...]
Another possibility is that the keys have been updated since you initially installed them and you need to remove the current key to allow dnf to import the updated key.
I think this is the case.
I was able to copy the yum repo file from there and install signal-libringrtc without issue. The key was imported during this install.
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
On Wed, 7 Aug 2024, Todd Zullinger wrote:
I wrote:
Max Pyziur wrote:
Greetings,
GPG Keys are configured as: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep...
Any guidance here would be appreciated.
[...]
Another possibility is that the keys have been updated since you initially installed them and you need to remove the current key to allow dnf to import the updated key.
I think this is the case.
I was able to copy the yum repo file from there and install signal-libringrtc without issue. The key was imported during this install.
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
Thank you. This worked.
Max
Todd Zullinger
Another possibility is that the keys have been updated since you initially installed them and you need to remove the current key to allow dnf to import the updated key.
Todd Zullinger:
I think this is the case.
I was able to copy the yum repo file from there and install signal-libringrtc without issue. The key was imported during this install.
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?
On Wed, Aug 7, 2024 at 7:08 PM Max Pyziur pyz@brama.com wrote:
On Wed, 7 Aug 2024, Todd Zullinger wrote:
I wrote:
Max Pyziur wrote:
Greetings,
GPG Keys are configured as:
https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/rep...
Any guidance here would be appreciated.
[...]
Another possibility is that the keys have been updated since you initially installed them and you need to remove the current key to allow dnf to import the updated key.
I think this is the case.
I was able to copy the yum repo file from there and install signal-libringrtc without issue. The key was imported during this install.
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
Thank you. This worked.
FYI, signal is available as a flatpak on Fedora
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-17280ddfI'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. :)
-
Max Pyziur -
Neal Becker -
Tim -
Todd Zullinger