Created attachment 1774235 [details] full dnf output Sometimes packages succesfully installed on computer A, fail with a GPG check error on computer B and C. Yet if I point dnf directly do the same RPM in the local repo, it updates without complaint. rpm-4.16.1.3-1.fc34.x86_64 dnf-4.6.1-1.fc34.noarch python3-dnf-plugin-local-4.0.19-1.fc34.noarch python3-dnf-plugins-extras-common-4.0.13-3.fc34.noarch libdnf-0.60.0-1.fc34.x86_64 From the attached full cli session: >shim-x64 x86_64 15.4-4 _dnf_local 466 k This is the RPM in this example. It's coming from _dnf_local which is made available by SMB on /media/repodir. >Package shim-x64-15.4-4.x86_64.rpm is not signed >Error: GPG check FAILED The messages are misleading. The RPMs are signed as shown by directly updating one: >[chris@flap ~]$ sudo dnf update /media/repodir/shim-x64-15.4-4.x86_64.rpm Same RPM, yet no GPG complaint.
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.