Bug 1416103

Summary: fedora-cisco-openh264 stopped working properly after upgrade to fedora 25
Product: [Fedora] Fedora Reporter: Petr Menšík <pemensik>
Component: dnfAssignee: rpm-software-management
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: high    
Version: 25CC: jmracek, mmraka, packaging-team-maint, rpm-software-management, vmukhame
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-14 10:47:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Petr Menšík 2017-01-24 15:29:13 UTC 
Description of problem:
I noticed the problem when trying to run fedora-review command. But found that 
it shows always when using cached query information.

Version-Release number of selected component (if applicable):
dnf-1.1.10-5.fc25.noarch
fedora-repos-0:25-1.noarch

How reproducible:
Always on my system.

Steps to Reproduce:
1. sudo dnf --enablerepo=fedora-cisco-openh264 repoquery --file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64 && echo works
2. dnf --enablerepo=fedora-cisco-openh264 repoquery --file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64 && echo works also
3. dnf --enablerepo=fedora-cisco-openh264 repoquery -C --file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64 || echo "asks me to import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64 key, but silently fails.

Actual results:
$ dnf --enablerepo=fedora-cisco-openh264 repoquery -C --file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
Importing GPG key 0xFDB19C98:
 Userid     : "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>"
 Fingerprint: C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
Is this ok [y/N]: y
Importing GPG key 0xFDB19C98:
 Userid     : "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>"
 Fingerprint: C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
Is this ok [y/N]: y
Error: Cache-only enabled but no cache for 'fedora-cisco-openh264'

I can repeat this again and again.

Expected results:
same as without -C
$ dnf --enablerepo=fedora-cisco-openh264 repoquery --file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
Fedora 25 openh264 (From Cisco) - x86_64        3.4 kB/s | 3.0 kB     00:00    
fedora-repos-0:25-1.noarch

Additional info:
I had to set enable=0 to cisco repository, so I can use fedora-review tool again.
Not sure whether it is related. I have Fedora GPG key in my personal keyring.

$ gpg --list-key "C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98"
pub   4096R/FDB19C98 2016-03-31
uid                  Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>
Comment 1 Honza Silhan 2017-02-06 12:29:35 UTC 
We should investigate why the key is in the cache for this repo and not in standard path. It should be stored in rpmdb.
Comment 2 Jaroslav Mracek 2017-03-14 10:39:50 UTC 
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.
Comment 3 Jaroslav Mracek 2017-03-14 10:47:23 UTC 

*** This bug has been marked as a duplicate of bug 1247644 ***