Bug 1814671 - include gpg of cisco repo
Summary: include gpg of cisco repo
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-repos
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mohan Boddu
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F32FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-03-18 13:56 UTC by Vladimir Benes
Modified: 2020-04-13 21:28 UTC (History)
16 users (show)

Fixed In Version: fedora-repos-32-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-13 21:28:54 UTC
Type: Bug


Attachments (Terms of Use)
dnf-output (62.61 KB, image/png)
2020-03-18 14:03 UTC, Martin Styk
no flags Details

Description Vladimir Benes 2020-03-18 13:56:47 UTC
Description of problem:
to continue this:
https://bugzilla.redhat.com/show_bug.cgi?id=1814596

is there any reason why we don't have gpg key of cisco repo bundled together with other fedora repos? We have GPG keys back to fedora 7 included in the package (why??) but we don't have the cisco one. 
Once a user installs the system it's needed to approve the gpg over a network. This is just breaking the smooth user experience.

Version-Release number of selected component (if applicable):
fedora-repos-32-0.7

Comment 1 Martin Styk 2020-03-18 14:03:32 UTC
Created attachment 1671067 [details]
dnf-output

Attached how it looks like w/ clean installation via ISO.
This is not really nice user experience if we have to accept the GPG key for CISCO repo. Why this repo is not handled as rest if it should be enabled by default.

Comment 2 Mohan Boddu 2020-03-18 14:47:05 UTC
openh264 rpms are signed with their respective fedora release gpg key, for example, https://src.fedoraproject.org/rpms/fedora-repos/blob/f32/f/fedora-cisco-openh264.repo#_10 uses Fedora 32 gpg key. We need to set "repo_gpgcheck = 0" to not to perform gpg check on repodata which makes it go away. I am not sure why it was set in first place as it predates me, maybe we can ask fedora-workstation guys.

Comment 3 Mohan Boddu 2020-03-18 16:18:12 UTC
The right fix for this issue is fixing other bz bug https://bugzilla.redhat.com/show_bug.cgi?id=1768206

Comment 4 Dennis Gilmore 2020-03-18 18:41:12 UTC
Ther reason that "repo_gpgcheck = 1" is set because it does not use mirrormanager it could be subject to man in the middle attacks and so we need to verify that the repodata is provided by fedora.

Comment 5 Michael Catanzaro 2020-03-20 13:30:56 UTC
Asking whether to import a GPG key from a *Fedora-packaged source* is already a mistake. That's just training users to ignore GPG key prompts. I don't even think about them anymore before I habitually enter y for yes....

Comment 6 Dusty Mabe 2020-03-20 16:15:32 UTC
After talking with Mohan, my understanding is that key that is used for the cisco repo is the same exact key that is used for the rest of Fedora 32 so the key is already local to the system. The "problem" is that there is a bug in DNF which doesn't properly detect the key and prompts the user anyway: https://bugzilla.redhat.com/show_bug.cgi?id=1768206#c5

If the above is correct then this bug should be closed since the gpg key for the cisco repo is already included as requested.

Comment 7 Martin Styk 2020-03-20 16:40:00 UTC
Right Dusty,..

In my opinion, DNF patch has to be introduced into Fedora 32. User experience is terrible if you will ask to add new GPG key on first DNF operation, even when user didn't touch OS.

Comment 8 Neal Gompa 2020-03-20 21:11:43 UTC
(In reply to Martin Styk from comment #7)
> Right Dusty,..
> 
> In my opinion, DNF patch has to be introduced into Fedora 32. User
> experience is terrible if you will ask to add new GPG key on first DNF
> operation, even when user didn't touch OS.

That already happens today anyway. We haven't been preloading the imported key for a while now.

Comment 9 Fedora Update System 2020-04-09 21:33:40 UTC
FEDORA-2020-e78e1f678b has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e78e1f678b

Comment 10 Adam Williamson 2020-04-09 21:36:05 UTC
Transferring F32 Final release blocker status here from https://bugzilla.redhat.com/show_bug.cgi?id=1768206 , as explained in https://bugzilla.redhat.com/show_bug.cgi?id=1768206#c29 .

Comment 11 Fedora Update System 2020-04-10 03:32:20 UTC
FEDORA-2020-2d37e7879c has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2d37e7879c

Comment 12 František Zatloukal 2020-04-10 08:49:08 UTC
FEDORA-2020-2d37e7879c fixes the issue.

Comment 13 Fedora Update System 2020-04-11 18:51:22 UTC
FEDORA-2020-2d37e7879c has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2d37e7879c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2d37e7879c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2020-04-13 21:28:54 UTC
FEDORA-2020-2d37e7879c has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


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