Bug 1952302

I think the commonality in these failures, is that these RPMs have been downloaded from koji, not a Fedora repo. They are successfully added to the _dnf_local repodir however, where they subsequently fail to install with this GPG check error.

First a couple of important notes:

1. Packages directly downloaded from koji are not signed at all. To explicitly see this you can do: 
$ wget https://kojipkgs.fedoraproject.org//packages/htop/3.0.5/1.fc33/x86_64/htop-3.0.5-1.fc33.x86_64.rpm && rpmkeys -v --define '_pkgverify_level signature' --checksig ./htop-3.0.5-1.fc33.x86_64.rpm

2. When you use dnf and specify a path to a package on the command line like:
> [chris@flap ~]$ sudo dnf update /media/repodir/shim-x64-15.4-4.x86_64.rpm
dnf doesn't check any signatures (see option 'localpkg_gpgcheck' from man dnf.conf), that is why you were able to update the package.


But I think there is also a more general limitation of the local plugin, it basically just throws all the packages into a single repo regardless of whether they are signed or by which key and then when used it tries to verify the signatures by default, so it kind of assumes the all the keys are already imported and packages are signed (this could also cause problems when using the repo on multiple computers).

With that said you can workaround this by using '--nogpgcheck' with dnf when installing from such a _dnf_local repo.

Not sure if this was actually helpful but it might clarify the situation a bit. 
For me it doesn't seem like a bug at this point as the behavior is expected.

Thanks for the explanation.

I ran into this today when I started using the dnf local plugin. Although you could say it's by design, it means the local plugin is unusable without globally setting `gpgcheck=0`, which I think isn't recommended. Using `--nogpgcheck` doesn't make much sense, since it acts as a cache and you don't know when packages will be used from it.

It would be a nice fix if the local plugin itself set `gpgcheck=0` for just the `_dnf_local` repo.