Description
An install trigger in tdnf
imports the packages.microsoft.com
public PGP keys using rpm --import
.
Separately, a post-transaction scriptlet from mariner-repos
imports said keys to root
's default GPG homedir
.
It appears that tdnf
(more specifically the repogpgcheck plugin by virtue of gpgme
) uses the keys in GPG's homedir
path (e.g., derived from HOME
) instead of the ones targeted by rpm --import
(e.g., /etc/pki/rpm-gpg/...
) as one would expect transitively from checkSig()
.
Critically, this means that operations that fail a gpg --verify
also fail tdnf
's repogpgcheck
. One salient example of this is setting HOME
to anything other than the implicit path established in the mariner-repos
scriptlet (namely, /root/.gnupg
by virtue of the gpg --import
) which is not an uncommon pattern in CI/CD scenarios. This particular one breaks tdnf
operations in GitHub Actions both with 1.0 and 2.0 container images.
(If you're here because you can't tdnf install
in a GitHub Action or similar containerized build environment you might want to set GNUPGHOME
to /root/.gnupg
)
Short of refactoring repogpgcheck
to use RPM bindings, another solution that comes to mind is to force-set GNUPGHOME
for CBL-Mariner container images. This sounds drastic, but might be a consequence of the decision of using gpg --import
in the mariner-repos
scriptlet. That operation implies /root/.gnupg
, which is then no longer referenced. Encoding it as an environment variable in container images would be one way to make that explicit. (So are other approaches: set it for the image itself, set it just for tdnf
executions, or set it in the gpgme_*
invocations.)
Also see #2752