Description of problem:
to continue this:
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):
Created attachment 1671067 [details]
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.
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.
The right fix for this issue is fixing other bz bug https://bugzilla.redhat.com/show_bug.cgi?id=1768206
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.
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....
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.
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.
(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.
FEDORA-2020-e78e1f678b has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e78e1f678b
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 .
FEDORA-2020-2d37e7879c has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2d37e7879c
FEDORA-2020-2d37e7879c fixes the issue.
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.
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.