Dnf GPG check fails with NO-SHA1 crypto-policy on legacy-signed third-party repo keys — scoped @rpm subpolicy doesn't unblock it

Support
1

System: AlmaLinux 9.8, kernel 5.14.0-687.36.1.el9_8 Crypto policy: DEFAULT:NO-SHA1:NO-SSHCBC (custom subpolicy for SSH hardening)

The problem

After hardening SSH by disabling SHA-1 system-wide (update-crypto-policies --set DEFAULT:NO-SHA1:NO-SSHCBC), dnf update started failing GPG checks on several third-party repos (CrowdSec, Varnish, Rspamd), with:

warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Could not load key gpg-pubkey-bf21e25e-55b7541f
...
GPG Keys are configured as: https://rspamd.com/rpm-stable/gpg.key
Error: GPG check FAILED

I confirmed with rpm --checksig -v that the package itself is signed with RSA/SHA256 (fine), but the GPG public key’s own self-certification uses SHA-1:

Header V4 RSA/SHA256 Signature, key ID bf21e25e: NOKEY
Header SHA256 digest: OK
Payload SHA256 digest: OK

I pulled the key fresh from https://rspamd.com/rpm-stable/gpg.key and confirmed with gpg --list-packets that it was created in 2015 and its self-signature uses digest algo 2 (SHA-1) — it’s never been rotated. So NO-SHA1 correctly refuses to load the key, and dnf can’t verify the package as a result, even though the package payload itself is signed with a modern algorithm.

What I tried that didn’t work

I assumed I could scope the SHA-1 exception to only the RPM backend, leaving SSH/TLS untouched, using a custom subpolicy:

# /etc/crypto-policies/policies/modules/RPM-SHA1.pmod
hash@rpm = SHA1+
sign@rpm = RSA-SHA1+


update-crypto-policies --set DEFAULT:NO-SHA1:NO-SSHCBC:RPM-SHA1
update-crypto-policies --check   # "The configured policy matches the generated policy"

Despite --check confirming the policy applied cleanly, rpm --checksig still fails identically, and dnf update still fails with the same GPG error. AlmaLinux 9 appears to use the rpm-sequoia backend for RPM signature verification (Sequoia-PGP), and it’s not clear whether the @rpm / @rpm-sequoia scope is actually being honored for key-loading in this backend, or whether Sequoia enforces its own certification policy independently of the crypto-policies scope.

What I’m trying to avoid

I don’t want to:

  • Disable gpgcheck entirely on the repo (gpgcheck=0)
  • Run dnf update --nogpgcheck
  • Roll back to DEFAULT:SHA1 globally (which would undo the SSH hardening this policy was set up for)
2

Hi,
might you have more success with first enabling SHA1 for everything, followed by adding a more restrictive policy just for SSH instead?