I think the problem here might be that linux_signing_key.pub contains both the 1024-bit DSA key with SHA-1 and a newer key.

rpmkeys should probably attempt to import all keys in the keyring by using https://docs.sequoia-pgp.org/sequoia_openpgp/cert/struct.CertParser.html. Something along the lines of

  let parser = sequoia_openpgp::cert::CertParser::from_file(path)?;
  for item in parser {
    // attempt import
  }

'rpmkeys --import' will actually import the good key, it'll just return an error code though. But dnf has it's own logic here which will import anything it finds in the provided key, but abort on any failures although the function ultimately only cares whether *something* from the import provides a key.

So fixing this is actually super simple:

diff --git a/dnf/base.py b/dnf/base.py
index 6d33e250..08f5c4a0 100644
--- a/dnf/base.py
+++ b/dnf/base.py
@@ -2606,7 +2606,8 @@ class Base(object):
                     self._ts.setFlags(orig_flags)
                 if result != 0:
                     msg = _('Key import failed (code %d)') % result
-                    raise dnf.exceptions.Error(_prov_key_data(msg))
+                    logger.warning(_prov_key_data(msg))
+                    continue
                 logger.info(_('Key imported successfully'))
                 key_installed = True
 

It's all a bit noisy, but it gets the job done:

# bin/dnf-3 -y --setopt=keepcache=True --enablerepo=google-chrome install google-chrome-stable
[...]
Downloading Packages:
[SKIPPED] google-chrome-stable-119.0.6045.159-1.x86_64.rpm: Already downloaded 
google-chrome                                    24 kB/s |  14 kB     00:00    
Importing GPG key 0x7FAC5991:
 Userid     : ""
 Fingerprint: 4CCA 1EAF 950C EE4A B839 76DC A040 830F 7FAC 5991
 From       : https://dl.google.com/linux/linux_signing_key.pub
error: Certificate A040830F7FAC5991:
  Policy rejects A040830F7FAC5991: No binding signature at time 2023-11-28T09:53:24Z
Key import failed (code 2). Failing package is: google-chrome-stable-119.0.6045.159-1.x86_64
 GPG Keys are configured as: https://dl.google.com/linux/linux_signing_key.pub
Importing GPG key 0xD38B4796:
 Userid     : "Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster>"
 Fingerprint: EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796
 From       : https://dl.google.com/linux/linux_signing_key.pub
warning: Certificate 7721F63BD38B4796:
  Policy rejects subkey 1397BC53640DB551: Policy rejected non-revocation signature (PrimaryKeyBinding) requiring second pre-image resistance
  Subkey 78BD65473CB3BD13 is expired: The subkey is not live
  Policy rejects subkey 6494C6D6997C215E: Policy rejected non-revocation signature (PrimaryKeyBinding) requiring second pre-image resistance
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  Running scriptlet: google-chrome-stable-119.0.6045.159-1.x86_64           1/1 
  Installing       : google-chrome-stable-119.0.6045.159-1.x86_64           1/1 
  Running scriptlet: google-chrome-stable-119.0.6045.159-1.x86_64           1/1 

Installed:
  google-chrome-stable-119.0.6045.159-1.x86_64                                  

Complete!

Ressigning to dnf. 

Neal, just FYI.

Hi, this issue has attracted the attention of Fedora Workstation Working Group (via https://pagure.io/fedora-workstation/issue/409) because it's causing updates to break for presumably all users with Google Chrome installed, which we assume is likely a huge percentage of Fedora Workstation users. Affected users will need to manually update to a fixed libdnf, because they won't be able to update automatically.

(In reply to Panu Matilainen from comment #2)
> So fixing this is actually super simple:

Could the dnf maintainers respond to this please? Does Panu's suggested fix look OK?

Proposed as a Blocker for 40-beta by Fedora user catanzaro using the blocker tracking app because:

 The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager). This includes downloading of packages to be installed/updated.

This issue was for a tighter-than-default cryptographic policy. If updates broke for users of the DEFAULT policy, you might want to file a separate issue.

I've just checked and confirmed this bug does not occur when using the default crypto policy. Sorry for the noise. Let's see if I can drop the blocker proposal....

Looks like this issue only happens when not using the default crypto policy?

If so, can we close this ticket?

No, I filed it so that I can change the DEFAULT crypto policy one day.

Should this be marked as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2274169 ?

No, basically, this bug is about a future change I'd like to land. If updating Chrome broken even under DEFAULT policy now, that sounds like a separate issue.

Ok, then since this is about a FutureFeature, I'll move it to Rawhide and mark it as FutureFeature so the bug doesn't age out / gets EOL-closed next week.

Still relevant, still blocks distrusting old weak algorithms (bz2342222)

I proposed a two-liner patch to address this dnf issue in comment #2.

This should be eventually handled by this upstream ticket: https://github.com/rpm-software-management/dnf5/issues/2037.

(In reply to Jan Kolarik from comment #14)
> https://github.com/rpm-software-management/dnf5/issues/2037.

My understanding of this plugin was that it works for keys that are already imported — does it also apply for keys on import?

(In reply to Clemens Lang from comment #15)
> (In reply to Jan Kolarik from comment #14)
> > https://github.com/rpm-software-management/dnf5/issues/2037.
> 
> My understanding of this plugin was that it works for keys that are already
> imported — does it also apply for keys on import?

Hmm, you're right, sorry about that. Was browsing through multiple similar bugs and misread this one.

I will bring up this one on our meeting, seems like a forgotten one.