why can't /etc/yum.repos.d/fedora-cisco-openh264.repo not store the GPG keys like EVERY OTHER repo somewhere *out of* /var/cache/(dnf|yum) so that you get not asked about the key after rm -rf /var/cache/dnf/* ONLY FOR THAT repo while all others are fine GPG-Schlüssel 0x81B46521 wird importiert: Benutzer-ID : »Fedora (24) <fedora-24-primary>« Fingerabdruck: 5048 BDBB A5E7 76E5 47B0 9CCC 73BD E983 81B4 6521 Von : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-24-x86_64 Ist dies in Ordnung? [j/N]: j Fedora 24 openh264 (From Cisco) - x86_64 20 kB/s | 2.8 kB 00:00 RPM Fusion for Fedora 24 - Free - Updates
This looks like a dnf bug to me. The fedora-cisco-openh264 repo uses signed repodata. dnf should keep track of the key and not ask you for it again when accessing the repodata. Moving to dnf for comment...
The gpg file is the same at the one used for the fedora, updates and updates-testing repos. it is stored in /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch the question seems to be due to the repodata being signed, something we intend to do for all repos asap. I am not sure that it is a bug anywhere just a usability issue. if you remove the imported version it has to be reimported, I am not sure we should just automatically import the key into dnf. However dnf perhaps could use the gpog keys imported by rpm.
normally keys are imported at first use and if that is they *only* repo where a rm -rf /var/cache/dnf/* is asking again something is wrong here - it's that simple [harry@srv-rhsoft:~]$ rpm -qa | grep pubkey gpg-pubkey-7fac5991-4615767f gpg-pubkey-b7546f06-5544d2dc gpg-pubkey-a6708da3-52ae2b2e gpg-pubkey-d38b4796-570c8cd3 gpg-pubkey-ff6382fa-3e1ab2ca gpg-pubkey-5ca6c469-548632d2 gpg-pubkey-97f4d1c1-52ae28d3 gpg-pubkey-f6777c67-45e5b1b9 gpg-pubkey-96ca6280-5544d430 gpg-pubkey-81b46521-55b3ca9a gpg-pubkey-34ec9cba-54e38751 gpg-pubkey-8e1431d5-53bcbac7 gpg-pubkey-e051b67e-54863278
rpm gpg key importing for verifying rpms and dnfs gpg importing for verifying repodata are two seperate tasks doing very different things, the only commonality between them is that they are the same key.
jesus christ - try it your self rm -rf /var/cache/dnf/* dnf upgrade the cisco repo is the only one which will ask again for confirmation of the gpg key
I know what it is doing, the issue is that the repodata is signed today, to the best of my knowledge dnf does not use the rpm db when verifying the signature on the repodata. dnf instead uses its own database which you throw away when doing that "rm -rf" I belive the result you are seeing is intentional. and you will see it soon with all fedora provided repos when we move to signing the repodata for all of the fedora repositories. I think you are making bad assumptions about how signed repos should actually work. It is something new, so I will leave it for a dnf dev to comment on if this is expected behaviour or not. rpm plays no part in the process for verifying the signed repodata if you look in https://codecs.fedoraproject.org/openh264/25/x86_64/repodata/ and compare it to http://dl.fedoraproject.org/pub/fedora/linux/updates/25/x86_64/repodata/ the repodata.xml.asc is the signature for the repodata and we have repo_gpgcheck=1 set in /etc/yum.repos.d/fedora-cisco-openh264.repo as opposed to repo_gpgcheck=0 in /etc/yum.repos.d/fedora-updates.repo and the other fedora provided repos. again the checking of the gpg key used to sign the repodata is something very different to checking of the gpg key used to sign individual rpms.
Since when belongs databases to /var/cache instead /var/lib and since when it's a smart idea using his own database when repo keys are already in the rpm database - sounds like NIH syndrome That all would not be needed if yum/dnf would be smart enough to apply "dnf clean" also on disabled repos which you had enabled with --enablerepo
I think we have here little bit different problem. Repo_gpg key is different that rpm gpg key. It is imported into cache directory with metadata. But user use different cache than root (for good security reason), therefore also import of gpg key is in different place. If we will allow to share gpg key location for users and root we will have to answer question who has rights to write down the gpg key? And what happen when key is changed? If user will not have rights he will be unable to use repo's gpg verification. From my point of view it is not a bug because if you import repo gpg key into cache it is valid for user that imported it and the logic is same like for metadata. Also I want to mention that this behavior is same like YUM used.
*** This bug has been marked as a duplicate of bug 1247644 ***