RPM version 4.16.1.3, failure to import some keys

[dvershinin]

The GPG public key cannot be installed with RPM version 4.16.1.3, found in CentOS Stream 9.

All prior OS versions had installed it just fine.

But with RPM 4.16.1.3 there's indeed an unhelpful error message (see #1974).

I did my due search, and the only relevant thread I've found was at 1password community about critical bits being set in some data, however, listing packets with gpg --list-packets reveals nothing critical...

Any help? I observe exactly the same issue with some keys pre-installed (but not imported) on CentOS 9 stream. For example:

[root@12ef34b385a2 rpm-gpg]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras: key 1 import failed.

But

[root@12ef34b385a2 rpm-gpg]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Extras-SHA512
# import fine, no error

[DemiMarie]

This is because the key’s subkey binding signature uses the weak SHA-1 hash algorithm. The -SHA512 suffix in your second command presumably indicates that it uses the strong SHA512 algorithm. Please contact getpagespeed and ask them to resign the key.

[dvershinin]

I have access to the getpagespeed secret key as I work there. I resigned like so:

gpg --cipher-algo IDEA --cert-digest-algo sha512 --expert --edit-key <KEY>

Then sign, and save.

But when exported with gpg --export --export-options export-minimal --armor > test-key, I still can't import it on the target CentOS Stream 9 machine with the same cryptic message. What am I doing wrong?

[DemiMarie]

I have access to the getpagespeed secret key as I work there. I resigned like so:

gpg --cipher-algo IDEA --cert-digest-algo sha512 --expert --edit-key <KEY>

Then sign, and save.

But when exported with gpg --export --export-options export-minimal --armor > test-key, I still can't import it on the target CentOS Stream 9 machine with the same cryptic message. What am I doing wrong?

You need to force GPG to regenerate the binding signatures on the subkeys. The easiest way I know to do that is to set an expiration date on the subkey, save the key, remove the expiration date, and then save the key again.

[pmatilai]

This is due to RHEL 9 openssl outlawing SHA1 use in signatures. Nothing rpm can do about it.

[nwalfield]

You need to force GPG to regenerate the binding signatures on the subkeys. The easiest way I know to do that is to set an expiration date on the subkey, save the key, remove the expiration date, and then save the key again.

FYI, sq-keyring-linter can be used to detect these types of issues:

$ sq-keyring-linter RPM-GPG-KEY-GETPAGESPEED 
Certificate 0CD60276222B0E83 is not valid under the standard policy: No binding signature at time 2022-03-29T12:26:08Z
Certificate 0CD60276222B0E83 contains a User ID ("GetPageSpeed Builder <info@getpagespeed.com>") protected by SHA-1
Certificate 0CD60276222B0E83, key 059A9010F4F3567D uses a SHA-1-protected binding signature.
...

And it can even fix them up, when that is appropriate:

$ gpg --export-secret-key KEYID | sq-keyring-linter --fix | gpg --import

(It's packaged for Fedora, too.)