search

rpm-software-management / dnf

Package manager based on libdnf and libsolv. Replaces YUM.
GNU General Public License v2.0
1.22k stars 405 forks source link

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

Open allanday opened 3 months ago

allanday commented 3 months ago

I'm using Fedora 39 with:

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 3 months ago

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 3 months ago

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.