check-update --cache-only does not work with repo_gpgcheck=1

[creshal]

If I run dnf makecache to create an up to date system cache (no errors, no warnings, all GPG keys imported into the system cache), and then run dnf check-update --cacheonly, it fails for various external repositories that have repo_gpgcheck enabled:

$ sudo -u foobar dnf check-update --cacheonly --assumeno
Importing GPG key [keyid]:
  [ . . . key details . . . ]
Error: Cache-only enabled but no cache for 'foo-rpm_release'

It does not matter whether the key is a local key under /etc/pki or via https, the error is the same; in any case, the root user has these keys successfully imported already.

It should be obvious that simply disabling gpg checking is not a proper solution.

[ppisar]

I'm sorry, I cannot reproduce it with the latest code from git repository. What dnf, libdnf, librepo, rpm versions do you use? Is your librepo built with gpgme or rpm (cmake -DUSE_GPGME=OFF) as a cryptographic backend?

"dnf makecache" does not import the key into RPM database. It copies it into dnf cache in /var/cache/dnf/REPO_ID-HASH/pubring directory and import it from there into RPM database later when an package with an unknown key is to be installed. If you librepo built with gpgme backend, then it's more complicated.

It looks like your DNF run under your non-root user does not have an access to the cached key.

[creshal]

Oracle Linux 8.9 and 9.3, so dnf 4.7.0 and 4.14.0, and librepo 1.14.2 to 1.14.5. As far as I can tell, they don't set any particular backend, and librepo links against gpgme on both.

It looks like your DNF run under your non-root user does not have an access to the cached key.

Indeed, but I have no idea why: Some GPG keys import just fine (bareos e.g., using its default script), some just don't work at all (prometheus-rpm works neither with its default https://… entry nor a locally downloaded file://… entry, and -v doesn't show any warnings/debug info. Makecache as root user imports the key just fine in all cases. (And the unprivileged users can read the key files just fine, there are no permission problems as far as I can see.)

Reproducing this with a fresh Rocky 9.3 VM:

• dnf makecache && sudo -u foo dnf check-update --cacheonly --assumeno works
• curl https://download.bareos.org/current/EL_8/add_bareos_repositories.sh | bash && dnf makecache && sudo -u foo dnf check-update --cacheonly --assumeno asks me once to import the key when makecache runs, then the unprivileged user can access it just fine
• Adding the prometheus repo (either with the .repo file from the git repo or the packagecloud script fails with above error
  • If I delete /var/cache/dnf and use a downloaded copy for the key in the .repo file, makecache asks me for both bareos and prometheus keys, bareos still is recognized, prometheus still fails

So I'm not sure why some keys are accessibly, but some not. I'll see if I can update dnf to the repository version on a test VM and if that fixes it.

[ThinLinc-Zeijlon]

I have encountered the same issue.

For context, we are running a Nagios NRPE script that runs the command

dnf --cacheonly --noplugins check-update

This is run the nrpe-user, and have been doing so, successfully on multiple machines for a long time. But when it's run on a machine that has the GitLab repository installed, the command fails.

When debugging i saw that the command asks for user input when it wants to import GitLabs GPG-key. I get a bit further by adding either --assumeno or --assumeyes, but I then end up with the output:

Error: Cache-only enabled but no cache for 'gitlab_gitlab-ee'

I have run dnf check-update beforehand as root, so the cache is most definitely present.

Is the GPG-check really needed when running dnf check-update?