see also: https://bugzilla.redhat.com/show_bug.cgi?id=2241019

Looks like this might be a bug in libdnf, not in rpm / rpm-sequoia.

Surprise!

I guess the solution here is revert the crypto-policies change until dnf is fixed?

I guess the solution here is revert the crypto-policies change until dnf is fixed?

How would someone get that change if they're unable to update?

Oh, I see this is a problem in Fedora 39, not Fedora 40. Well drat.

see also: https://bugzilla.redhat.com/show_bug.cgi?id=2241019

I've pinged the dnf maintainers and proposed this as an F40 release blocker. Too bad we didn't notice until now, since it seems this has been broken since prior to the F39 release.

see also: https://bugzilla.redhat.com/show_bug.cgi?id=2241019

Alexander mentioned that bug occurs only in a non-default configuration with strict crypto policies enabled. I've tested and confirmed that it's possible to install Google Chrome with default crypto policies, and Allan has confirmed that he's using the default crypto policies. So that looks like a separate bug, unrelated to this issue?

Ok, I was able to reproduce a simpler issue:

• on an up-to-date Fedora 39 Workstation install (fresh F39 install)
• with "Enable third-party repositories" enabled in g-i-s
• in GNOME Software, selected Google Chrome RPM from the google-chrome repo
• hit "Install" button

You get this error:

package google-chrome-stable-121.0.6167.85-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-121.0.6167.85-1.x86_64.rpm could not be verified.
/var/cache/PackageKit/39/metadata/google-chrome-39-x86_64/packages/google-chrome-stable-121.0.6167.85-1.x86_64.rpm:  digest:  SIGNATURE:  NOT OK

So this is the case for both first-time installs and for upgrades.

Installing the RPM with dnf (sudo dnf install google-chrome-stable), you get this:

Importing GPG key 0x7FAC5991:
 Userid     : "Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>"
 Fingerprint: 4CCA 1EAF 950C EE4A B839 76DC A040 830F 7FAC 5991
 From       : https://dl.google.com/linux/linux_signing_key.pub
Is this ok [y/N]: y
warning: Certificate A040830F7FAC5991:
  Policy rejects subkey 4F30B6B4C07CB649: Policy rejected asymmetric algorithm
Key imported successfully
Importing GPG key 0xD38B4796:
 Userid     : "Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>"
 Fingerprint: EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796
 From       : https://dl.google.com/linux/linux_signing_key.pub
Is this ok [y/N]: y 
warning: Certificate 7721F63BD38B4796:
  Subkey 1397BC53640DB551 is expired: The subkey is not live
  Subkey 78BD65473CB3BD13 is expired: The subkey is not live
  Subkey 6494C6D6997C215E is expired: The subkey is not live
Key imported successfully

And the package installs fine. So ... it appears that rpm handles this fine, dnf handles this fine, but PackageKit does not? Does the libdnf PackageKit backend use a different code path for importing GPG keys than /usr/bin/dnf?

Neal is saying that PackageKit has not very much code to deal with this, and that he suspects libdnf is to blame. Anyway, we'll certainly need a bug report somewhere.

I'm still unable to install updates.

I'm still unable to install updates.

There isn't any bug report for this yet, except this one here. It won't be fixed without a bug report. Neal suggests libdnf would be the correct component.

Action item: Neal and Kalev to determine which component to report a bug against. Allan to report the bug.

Chat from the other day:

Kalev: I think your update problem is two fold. The first issue like Conan Kudo mentioned seems to be a libdnf issue that it never re-downloads the GPG key - it looks like the dnf cli utility re-downloads it, so it would make sense to for the part of libdnf that PackageKit uses to behave the same. Otherwise if the GPG key ever changes (and apparently it has changed) it can never recover from this situation.

Conan Kudo: I suspect I don't hit this because I use dnf system upgrade, and that fixes it.

Kalev: The second issue might actually be PackageKit issue that it doesn't skip over a broken repository - this one is marked as skip_if_unavailable=True so it should in theory get skipped if there is a problem with it. Or it might be a libdnf issue as well, it's a bit unclear to me how it should all work.

Conan Kudo: That's a libdnf thing too. PK doesn't care and just asks libdnf to do stuff.

Kalev: Yeah, but maybe there is a more detailed way of doing this where PK could itself iterate over repos and skip broken ones. In this case it might be fixable on PK side :)

So, PackageKit?

Action item: Allan to report libdnf bug

Reported here: https://github.com/rpm-software-management/libdnf/issues/1649

Also reported in Bugzilla now: https://bugzilla.redhat.com/show_bug.cgi?id=2274169