Bug 1416103 - fedora-cisco-openh264 stopped working properly after upgrade to fedora 25
Summary: fedora-cisco-openh264 stopped working properly after upgrade to fedora 25
Keywords:
Status: CLOSED DUPLICATE of bug 1247644
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 25
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-24 15:29 UTC by Petr Menšík
Modified: 2017-03-14 10:47 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-14 10:47:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1398868 0 unspecified CLOSED fedora-cisco-openh264.repo saves ggp-key on a unusual place 2021-02-22 00:41:40 UTC

Internal Links: 1398868

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>"
 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>"
 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>

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 ***


Note You need to log in before you can comment on or make changes to this bug.