Open dustymabe opened 3 years ago
Copying over this bit https://github.com/coreos/fedora-coreos-tracker/issues/925#issuecomment-899785161 - it looks like the real issue may be in librpm. A big difference between dnf and libdnf is that the former uses gpg to parse the key, whereas libdnf uses rpm's bespoke PGP code.
I get the same error message from trying
$ rpm --import f37.pgp
error: f37.pgp: key 1 not an armored public key.
$
ok https://src.fedoraproject.org/rpms/fedora-repos/pull-request/112 merged, but...
should we try to get the underlying libraries fixed so we don't have this problem in the future?
should this issue be transferred to be against rpm?
aha, thank you for figuring this out, colin! I got around to it today and was banging my head against it. It affects anything PackageKit-based, for the record - pkcon refresh
prompts for 'untrusted packages' because of it, and both Cockpit and GNOME Software show this "is not a GPG key" error.
Can we still drive down on this issue and fix the underlying library so we don't hit this again?
Hi, any progress on this?
I have to run a specific application for work (Keybase) on Fedora Silverblue and its repo is affected by this. So, instead of having it be updated along with the system, I have to disable the repo and every once in a while I have to manually install the rpm so it replaces the old one.
Apparently this will have to be fixed for Fedora 37 anyway, but any chance it could be fixed earlier? Maybe at least in time for Fedora 36?
Still a problem; Kubernetes gpg package key and/or repo key don't parse: https://packages.cloud.google.com/yum/doc/yum-key.gpg (this under latest Fedora CoreOS 36).
If folks want RPM's GPG key parsing to be more tolerant of whitespace issues, then someone needs to file an issue against RPM. It can't be fixed in libdnf.
I believe the new GPG introduced in https://src.fedoraproject.org/rpms/fedora-repos/c/688de4b2d4bf3411433d7e0978030b3a2cb37795?branch=rawhide is causing issues for microdnf and rpm-ostree (consumers of libdnf):
While
dnf
itself seems fine with the new key. Can someone look into what the issue is with the new key?Originally reported over in https://github.com/coreos/fedora-coreos-tracker/issues/925