gnome-software failing to prepare updates due to google-chrome signing error

[allanday]

I'm using Fedora 39 with:

• dnf-4.18.1-1.fc39.src.rpm
• gnome-software-45.1-1.fc39.src.rpm

In GNOME Software I have a list of outstanding software updates. If I press the Download button, it tries to prepare the update but then shows an error:

package google-chrome-stable-123.0.6312.86-1.x86_64 cannot be verified and repo google-chrome is GPG enabled: /var/cache/PackageKit/39/metadata/google-chrome-39-x86_64/packages/google-chrome-stable-123.0.6312.86-1.x86_64.rpm could not be verified.
/var/cache/PackageKit/39/metadata/google-chrome-39-x86_64/packages/google-chrome-stable-123.0.6312.86-1.x86_64.rpm:  digest:  SIGNATURE:  NOT OK

I was given advice that libdnf is the right place to report this issue. There's some downstream discussion here: https://pagure.io/fedora-workstation/issue/409

[jan-kolarik]

Hi, thanks for the report. I see it also on Bugzilla, so let's keep just one instance of this issue and close this one. We'll try to triage the problem during the following week.

[ppisar]

This is a bug in _get_key_for_package() of dnf/base.py:

If a repository keyring contains multiple primary keys and a key cannot be imported (e.g. librpm rejects), an exception is raised on the first failed key. This is suboptimal because importing other key from the keyring could be sufficient to verify RPM packages as in this case of google-chrome keyring https://dl.google.com/linux/linux_signing_key.pub.

I proposed raising an exception only if none of keys was not successfully imported. That logic makes DNF more resilient against keyrings with old, weak, expired, or unused keys.