More errors, this time with fedora-cisco-openh264 repository: 

# dnf install gstreamer1-plugin-openh264 mozilla-openh264 -vvvv
Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repograph, repomanage, reposync, system-upgrade
DNF version: 2.7.5
cachedir: /var/cache/dnf
repo: using cache for: jorti-pass-otp
not found deltainfo for: Copr repo for pass-otp owned by jorti
not found updateinfo for: Copr repo for pass-otp owned by jorti
jorti-pass-otp: using metadata from dom 01 abr 2018 10:26:03 CEST.
repo: using cache for: adobe-linux-x86_64
not found deltainfo for: Adobe Systems Incorporated
not found updateinfo for: Adobe Systems Incorporated
adobe-linux-x86_64: using metadata from mar 27 mar 2018 05:12:51 CEST.
Cannot download 'https://codecs.fedoraproject.org/openh264/28/x86_64/': repomd.xml GPG signature verification error: gpgme_op_verify() error: General error.
Error: Failed to synchronize cache for repo 'fedora-cisco-openh264'

This issue is not limited to Fedora28, but also reproducible in Fedora27.

The issue seems to occur only when adding new repositories on a *fully updated* Fedora installation.
Adding the same repo's in a fresh install but before updating works fine.

The combination of the error "GPG signature verification error: gpgme_op_verify() error: General error." and the fact that the following 2 packages have been recently updated:
# rpm -qa|grep gnupg2
gnupg2-2.2.6-1.fc27.x86_64
gnupg2-smime-2.2.6-1.fc27.x86_64

make me think it's a GPG verification/key management issue when adding a new repo.



For reference, the repo's I'm using:

# cat kubernetes.repo 
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

cat virtualbox.repo 
[virtualbox]
name=Fedora $releasever - $basearch - VirtualBox
baseurl=http://download.virtualbox.org/virtualbox/rpm/fedora/$releasever/$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://www.virtualbox.org/download/oracle_vbox.asc


Also note, more users are experiencing this issue, some annecdotal evidence:
https://github.com/NVIDIA/nvidia-docker/issues/706#issuecomment-382541638

This appears to be fixed upstream:

    https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=e2bd152a928d79ddfb95fd2f7911c80a1a8d5a21

I've applied that to gnupg2 and confirmed that it resolves the issue for me.

A pull request to apply this change to the gnupg2 package is here:

    https://src.fedoraproject.org/rpms/gnupg2/pull-request/1

Let me know if I can help with getting that pushed out to current releases.

I kicked off scratch builds in case anyone wants to test:

f29 https://koji.fedoraproject.org/koji/taskinfo?taskID=26480308
f28 https://koji.fedoraproject.org/koji/taskinfo?taskID=26480309
f27 https://koji.fedoraproject.org/koji/taskinfo?taskID=26480310
f26 https://koji.fedoraproject.org/koji/taskinfo?taskID=26480311

Proposed as a Freeze Exception for 28-final by Fedora user tmz using the blocker tracking app because:

 This bug prevents enabling repositories which enable repo_gpgcheck by default, like the fedora-cisco-openh264 repo which is shipped in fedora-repos.

A fix is in place upstream and I've filed a PR to fix the gnupg2 package, so it should be an easy change.

Reading further, after finding other issues with gpgme-1.10.0 and gnupg-2.2.6, upstream decided to patch gpgme instead.  That patch is now applied to the gpgme package on f27 and f28, with rawhide being updated to 1.11.1, which is not affected.

Updates don't seem to have been submitted.  There was some discussion on whether to submit updates in the gpgme PR (https://src.fedoraproject.org/rpms/gpgme/pull-request/3).  I've noted there that this bug affects more common user activities and likely warrants updates sooner rather than later.

Some references from upstream:

    https://gnupg.org/#sec-3-2 (recommends the gpgme patch)
    https://lists.gnupg.org/pipermail/gnupg-users/2018-April/060203.html (thread discussion the initial issue and subsequent problems found which led to patching gpgme rather than gnupg)

Reassigning to gpgme since it's the root of the bug (and already has an existing patch and koji builds).

gpgme-1.10.0-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-82760371c4

gpgme-1.10.0-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-82760371c4

Discussed at 2018-04-23 freeze exception review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-04-23/f28-blocker-review.2018-04-23-16.00.html . Accepted as a freeze exception issue: this could potentially affect enabling repositories before the system is updated, so it cannot be fully addressed with an update, and ensuring it's fixed on the release media seems desirable.

For the upgrade case, is it also important that the f27 update is in place or will the dnf system-upgrade be using the f28 package set by that point?  If not, we might also need to push an f26 update.

Also, in the even that someone still runs into the issue, there's a few way to work around it.  Here's an excerpt from some testing I did over the weekend when this came up in #fedora with respect to the fedora-cisco-openh264 repo:

### Disable gpg checking and run repolist (with only the affected repo,
### though since no other fedora repos enable repo_gpgcheck by default, this
### was just overly cautious.
# dnf --nogpgcheck --disablerepo '*' --enablerepo fedora-cisco-openh264 repolist
Fedora 27 openh264 (From Cisco) - x86_64        8.4 kB/s | 2.8 kB     00:00
Last metadata expiration check: 0:00:00 ago on Sat Apr 21 21:32:06 2018.
repo id                    repo name                                      status
fedora-cisco-openh264      Fedora 27 openh264 (From Cisco) - x86_64       7

### Now list the repo with gpg checking enabled while the repo cache is still 
### valid.  dnf prompts to install the repo key and successfully installs it.
[root@d5849fadfc13 /]# dnf --disablerepo '*' --enablerepo fedora-cisco-openh264 list openh264
Importing GPG key 0xF5282EE4:
 Userid     : "Fedora 27 (27) <fedora-27>"
 Fingerprint: 860E 19B0 AFA8 00A1 7518 81A6 F55E 7430 F528 2EE4
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-27-x86_64
Is this ok [y/N]: y
Fedora 27 openh264 (From Cisco) - x86_64         13 kB/s | 2.8 kB     00:00
Last metadata expiration check: 0:00:00 ago on Sat Apr 21 21:32:22 2018.
Installed Packages
openh264.x86_64               1.6.0-5.fc27                @fedora-cisco-openh264
Available Packages
openh264.i686                 1.6.0-5.fc27                fedora-cisco-openh264

This was taken from a paste I made to demonstrate the issue and workaround, here: https://paste.fedoraproject.org/paste/VIYYKUP08uZeqNVlptzTnw

Ideally no one will need to use this silly workaround, but I thought I would mention it in case anyone is curious.

More important is whether we need to ensure f26 and f27 also get the gpgme update before f28 is released.  I'm not sure it is, but it's also probably worth having just to be sure.  It is a one-line patch recommended by upstream, so it shouldn't be terribly risky.

gpgme-1.10.0-4.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.