If I run the underlying gpg2 command that's run by "sa-update --import", I see this:

gpg2 --homedir /etc/mail/spamassassin/sa-update-keys --import /tmp/GPG.KEY 
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: key 4056A61A5244EC45: 3 bad signatures
gpg: key 4056A61A5244EC45: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

Invoking with --allow-weak-digest-algos seems to allow the import to succeed:

gpg2 --allow-weak-digest-algos --homedir /etc/mail/spamassassin/sa-update-keys --import /tmp/GPG.KEY 
gpg: key 4056A61A5244EC45: public key "updates.spamassassin.org Signing Key <release>" imported
gpg: Total number processed: 1
gpg:               imported: 1

The sa-update.cron script still fails:

/usr/share/spamassassin/sa-update.cron
Terminated
Update available for channel updates.spamassassin.org: -1 -> 1911365
http: (curl) GET https://www.sa-update.pccc.com/1911365.tar.gz, success
http: (curl) GET https://www.sa-update.pccc.com/1911365.tar.gz.sha512, success
http: (curl) GET https://www.sa-update.pccc.com/1911365.tar.gz.asc, success
gpg: process '/usr/bin/gpg2' finished: exit 2
error: GPG validation failed!
The update downloaded successfully, but the GPG signature verification
failed.
channel 'updates.spamassassin.org': GPG validation failed, channel failed
Update failed, exiting with code 4
01-Aug-2023 14:31:33: SpamAssassin

I'm guessing because it calls gpg internally and that also needs --allow-weak-digest-algos

It looks like maybe the problem here is that gnpug2 version 2.3.3-3 disabled SHA-1:

* Thu Mar 30 2023 Jakub Jelen <jjelen> - 2.3.3-3
- Mark SHA-1 digest as weak to follow SHA-1 disablement in RHEL9 (#2070722)
- Fix interaction with SSH by not requiring the MD5 digest (#2073567)
- Fix creation of AEAD packets (#2128058)

How to fix?

So I downgraded to gnupg2-2.3.3-2.el9.x86_64.rpm, and now sa-update.cron works again.
So there's a conflict here.

I guess one option is to patch the /usr/bin/sa-update script to invoke gpg2 with
the --allow-weak-digest-algos option:

--- sa-update.orig      2022-01-17 05:33:16.000000000 -0500
+++ sa-update   2023-08-01 15:00:29.908775065 -0400
@@ -354,6 +354,7 @@ if (defined $opt{'gpgkeyfile'}) {
 
 # At this point, we need to know where GPG is ...
 my $GPGPath;
+my $gpgopts = "--allow-weak-digest-algos";
 if ($GPG_ENABLED || $opt{'import'}) {
   # find GPG in the PATH
   # bug 4958: for *NIX it's "gpg", in Windows it's "gpg.exe"
@@ -916,7 +917,7 @@ foreach my $channel (@channels) {
 
     # TODO: we could also use "--keyserver pgp.mit.edu" or similar,
     # to autodownload missing keys...
-    my $CMD = "$GPGPath $gpghome --verify --batch ".
+    my $CMD = "$GPGPath $gpgopts $gpghome --verify --batch ".
         "--no-tty --status-fd=1 -q --logger-fd=1";
 
     unless (open(CMD, "$CMD $sig_file $content_file|")) {
@@ -1817,7 +1818,7 @@ sub import_gpg_key {
   my $gpghome = interpolate_gpghomedir();
   check_gpghomedir();
 
-  my $CMD = "$GPGPath $gpghome --batch ".
+  my $CMD = "$GPGPath $gpgopts $gpghome --batch ".
       "--no-tty --status-fd=1 -q --logger-fd=1 --import";
 
   unless (open(CMD, "$CMD $keyfile|")) {

I guess that probably fixes it, but I need to wait for another spamassassin update to know for sure.

Thank you very much for reporting this problem!

This is indeed due to gnupg2 dropping SHA1 support in 2.3.3-3, but I can see the maintainer of it soon realized there are still plenty of SHA1 keys in the wild so he reverted this change in gnupg2-2.3.3-4.el9:

https://gitlab.com/redhat/centos-stream/rpms/gnupg2/-/commit/f011a7be8f3c6a5477f54242c924d920fb5876c8
https://gitlab.com/redhat/centos-stream/rpms/gnupg2/-/commit/fac10d0d25c2f70085c4736552150e0eed4ffb6b
https://kojihub.stream.rdu2.redhat.com/koji/buildinfo?buildID=32017

So if you upgrade to that version, that should fix this problem for you.

Given the information above, closing this as a duplicate of bug 2184640.

*** This bug has been marked as a duplicate of bug 2184640 ***

(In reply to Martin Osvald 🛹 from comment #4)
> Thank you very much for reporting this problem!
> 
> This is indeed due to gnupg2 dropping SHA1 support in 2.3.3-3, but I can see
> the maintainer of it soon realized there are still plenty of SHA1 keys in
> the wild so he reverted this change in gnupg2-2.3.3-4.el9:
> 
> https://gitlab.com/redhat/centos-stream/rpms/gnupg2/-/commit/
> f011a7be8f3c6a5477f54242c924d920fb5876c8
> https://gitlab.com/redhat/centos-stream/rpms/gnupg2/-/commit/
> fac10d0d25c2f70085c4736552150e0eed4ffb6b
> https://kojihub.stream.rdu2.redhat.com/koji/buildinfo?buildID=32017
> 
> So if you upgrade to that version, that should fix this problem for you.

Hi, wow, so this is really weird. I don't see that new release of
gnupg2 in CentOS Stream 9. More surprisingly, I no longer see gnupg2-2.3.3-3
in the CentOS stream repository. When I list the gnupg2 packages in the baseos
repo, 2.3.3-3 has magically disappeared:

repoquery --disablerepo='*' --enablerepo=baseos gnupg2
gnupg2-0:2.3.1-3.el9.x86_64
gnupg2-0:2.3.3-1.el9.x86_64
gnupg2-0:2.3.3-2.el9.x86_64

Did they somehow retract gnupg2-2.3.3-3 instead of pushing out 2.3.3-4?
I didn't know that was a concept. How can people properly maintain the O/S
when updates disappear like that? Does dnf somehow know to downgrade?

Regards,
Andy

(In reply to Andrew Schorr from comment #6)
...
> > So if you upgrade to that version, that should fix this problem for you.
> 
> Hi, wow, so this is really weird. I don't see that new release of
> gnupg2 in CentOS Stream 9.

Ah sorry, yes, it didn't get released yet, but you can download and update it by hand from the:

https://kojihub.stream.centos.org/koji/buildinfo?buildID=32017

~~~
# dnf update https://kojihub.stream.centos.org/kojifiles/packages/gnupg2/2.3.3/4.el9/x86_64/gnupg2-2.3.3-4.el9.x86_64.rpm
~~~

> ... More surprisingly, I no longer see gnupg2-2.3.3-3
> in the CentOS stream repository. When I list the gnupg2 packages in the
> baseos
> repo, 2.3.3-3 has magically disappeared:
> 
> repoquery --disablerepo='*' --enablerepo=baseos gnupg2
> gnupg2-0:2.3.1-3.el9.x86_64
> gnupg2-0:2.3.3-1.el9.x86_64
> gnupg2-0:2.3.3-2.el9.x86_64
> 
> Did they somehow retract gnupg2-2.3.3-3 instead of pushing out 2.3.3-4?

It looks like they retracted it maybe due to this problem. Not sure about the process and how it is done though. This is more questions for bug 2184640.

> I didn't know that was a concept. How can people properly maintain the O/S
> when updates disappear like that? Does dnf somehow know to downgrade?

Again I am not fully sure about this, but dnf has metadata that can be updated and no longer contain info about this update/version.