GPG : no more signatures of a fresh imported key

Question

SHORT

GPG doesn't get signatures of an imported public key anymore (with Ubuntu 20.04) while it did it 6 months ago (with Ubuntu 18.04). I don't understand what's wrong.

LONG

On march, I followed this mini HOW-TO in order to verify an Ubuntu ISO. And when I imported the public key which signed the checksum file to verify the ISO file, I had a message saying this new key had 72 signatures. I listed the signatures of this key, so I could find fingerprints and import these 72 public keys. And so on, I could move up the chain of trust until I could find a trustable key (if I understood everything).

But since this date, I've reinstalled my OS, so all GPG keys have been deleted. And now, when I do the same manipulation, the first imported public key has no signatures at all. So how can I move up the chain of trust ?

Is there something I'm missing ? Thanks for your help.

Below are the commands done on March and today to see the differences.

1) Commands on March with Ubuntu 18.04 (Yes, I copied it at this time to have an example) :

$ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: key D94AA3F0EFE21092: 2 duplicate signatures removed
gpg: key D94AA3F0EFE21092: 72 signatures not checked due to missing keys
gpg: key D94AA3F0EFE21092: public key "Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --list-signatures 843938DF228D22F7B3742BC0D94AA3F0EFE21092
pub   rsa4096/D94AA3F0EFE21092 2012-05-11 [SC]
      843938DF228D22F7B3742BC0D94AA3F0EFE21092
uid                 [ unknown] Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>
sig 3        D94AA3F0EFE21092 2012-05-11  Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>
sig          0BFB847F3F272F5B 2012-05-11  [User ID not found]
sig          393587D97D86500B 2012-05-11  [User ID not found]
sig          5759F35001AA4A64 2012-05-12  [User ID not found]
...

2) Commands of today with Ubuntu 20.04

$ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: key D94AA3F0EFE21092: public key "Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --list-signatures 843938DF228D22F7B3742BC0D94AA3F0EFE21092
pub   rsa4096 2012-05-11 [SC]
      843938DF228D22F7B3742BC0D94AA3F0EFE21092
uid           [ unknown] Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>
sig 3        D94AA3F0EFE21092 2012-05-11  Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>

$ 

As we can see in command of today, there are no more 72 signatures.

Answer 1

Sadly, it's the usual reason why whe can't have nice things: someone found out how to abuse the GPG ecosystem, and then did exactly that.

The SKS keyserver network has had known vulnerabilities for several years, and in mid-2019 someone finally started exploiting those vulnerabilities in significant volume, resubmitting legitimate users' public keys after adding fake user IDs or revocation certificates, or simply adding ridiculous numbers of signatures to keys.

https://code.firstlook.media/the-death-of-sks-pgp-keyservers-and-how-first-look-media-is-handling-it

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

As a result, the GPG "web of trust" got some major damage done to it, and GPG had to be updated to be more careful about "poisoned" keys, revocation certificates and signatures. On new installations, the default settings of GPG will (hopefully) now be adapted to the new situation.

To mitigate the damage, a new keyserver implementation, "Hagrid", strips all (non-self) signatures from keys, and in order to have an user ID attached to the key, a double opt-in validation is needed. Sadly, that complicates rebuilding of the trust chains. You can still get the actual key material from the keyservers, but you'll need to do more of your own legwork to determine whether you'll trust the identity associated with the key or not.