Contribute to Qubes-OS : how to get a valid GPG key for the signature-checker bot?

User Support
1

I contributed twice to qubes-os repositories: here and here.

But each time I got the Unable to verify (no valid key found) error from signature-checker bot. And now, I wish to contribute again without getting this issue.

When I created my GPG key, I followed the Code Signing documentation, with uploading my key to sks-kerservers.

Signature-checker executes the below (simplified) command (see line 100 of check-git-signature for the exact command):

user@qubes-dev:~$ gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 0x552BC8B26E38D080
gpg: keyserver receive failed: General error

If I remove the hkps protocol, it works:

user@qubes-dev:~$ gpg --keyserver pool.sks-keyservers.net --recv-key 0x552BC8B26E38D080
gpg: key 0x33FB8B0D7B886BE9: "Ludovic Bellier (lubellier) <xxx@yyy.zzz>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

GnuPg.net also recognizes my key.

So where I’m wrong? Any help/advice for getting my key recognized by signature-checker?

2

It’s the key servers, not you. See comments on:

3

@adw
Thanks for the information.

4

Looks like this subject is not over, I can’t be verified either.

It looks like pool.sks-keyservers.net is just not valid any more, the domain name does not even resolve:

$ host pool.sks-keyservers.net 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

Host pool.sks-keyservers.net not found: 3(NXDOMAIN)

gpg’s error message on this is quite surprising:

$ gpg --keyserver hkp://pool.sks-keyservers.net  --recv-keys 74AF05DDD92027F5F0C3CDD50D85F29625A3F9FD
gpg: keyserver receive failed: No name

In fact the cert on https://sks-keyservers.net/ has expired 3 months ago, it looks like we should find an alternative keyserver.

The check-git-signature script has a fallback to keys.openpgp.org, but receiving from that one just does not work well (despite exit(0) on gpg side):

$ gpg --keyring $(mktemp) --no-default-keyring --keyserver hkps://keys.openpgp.org  --recv-key 74AF05DDD92027F5F0C3CDD50D85F29625A3F9FD
gpg: key 0D85F29625A3F9FD: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

gnupg - gpg: can't import key: "new key but contains no user ID - skipped" - Super User teaches that openpgp.org strips userids, and it does not look like the gpg versions in debian-10 or fedora-32 will provide an option to recv those keys. And hints about hkps://keyserver.ubuntu.com, which does work AFAICT.

Am I alone in finding all those small facts about pgp/gpg quite scary ?

5

Correct. Sadly, it has died.

This is why we recently switched to keys.openpgp.org for all keyserver links on the team page:

Unfortunately, for the reasons you’ve discovered, keys.openpgp.org does not work for keys whose UIDs do not have email addresses, such as the Qubes Master Signing Key and release signing keys. However, we provide many alternatives here: Verifying signatures | Qubes OS

In addition, the Ubuntu keyserver you mentioned should still work for these keys.

1 Like
6

The problem seems to be deeper than just “keys whose UIDs do not have email addresses”: any key uploaded there gets stripped of their UID, AFAICT. Try to get any key there – I only tested a handful from the team’s page but all of them suffer from this:

$ gpg --keyring $(mktemp) --keyserver hkps://keys.openpgp.org --recv-keys 0064428F455451B3EBE78A7F063938BA42CFA724
gpg: key 063938BA42CFA724: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

I fail to see what this server can be useful for, in fact :slight_smile:

7

No, you’re misunderstanding how it works. Please read this:

https://keys.openpgp.org/about

I just tried importing all 12 core team member keys. Seven imported successfully, while five were skipped due to lack of UID. So, the majority import successfully. Most of those skipped are not developers. I already emailed all core team members two weeks ago and encouraged them to verify their keys, but we can’t force anyone to do it.

8

Oh right, I had missed that, thanks for correcting.

(I know I should not blindly trust everything written on stackoverflow and friends :wink: )