rpm-software-management/dnf

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

allanday opened this issue · 2 comments

allanday commented

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 commented

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 commented

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.

  • 👍2