Re: Finding a “good” OpenPGP key server

[Philip McGrath <philip@philipmcgrath.com>]

Hi,

On 4/18/22 16:24, Ludovic Courtès wrote:
> Hi,
> 
> Tanguy LE CARROUR <tanguy@bioneland.org> skribis:
> 
>> gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
>> gpgv:                using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
>> gpgv: Can't check signature: No public key
>> Would you like to add this key to keyring '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
>> yes
>> gpg: keyserver receive failed: No data
> 
> This indicates that ‘guix refresh’ failed to download the relevant GPG
> key from the default key server, the one that appears in
> ~/.gnupg/dirmngr.conf (if it exists).
> 
> That’s unfortunately often the case these days.  :-/ This key appears to
> be on keys.openpgp.org, but it lacks a “user ID” packet and so gpg
> ignores it (for no good reason):
> 
> --8<---------------cut here---------------start------------->8---
> $ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --keyserver keys.openpgp.org --recv-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpg: key D6B570842F7E7F8D: no user ID
> gpg: Total number processed: 1
> $ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --list-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpg: error reading key: No public key
> --8<---------------cut here---------------end--------------->8---
> 
> I’m not sure what a good solution is (other than looking for the key
> manually on Savannah or on some random key server).
> 

Many distributions of GnuPG include a patch to handle keys without “user 
ID” packets.[1] In fact, it may well be *most* distributions: Debian, 
Fedora, Nix, OpenSUSE[2], and at least one commonly-recommended 
installation option for Mac. Debian packagers have argued [3]:

> I think GnuPG's inability to receive these
> kinds of cryptographic updates to OpenPGP certificates that it knows
> about is at core a security risk (it makes it more likely that users
> will use a revoked key; or will be unable to use any key at all, and
> will send plaintext).

Unfortunately, the upstream GnuPG maintainer has rejected the patch, I 
guess because strict conformance to the OpenPGP standards requires user 
ids.[4]

I am by no means an expert on PGP or GPG issues, but I'd be in favor of 
Guix adopting this patch.

-Philip

[1]: https://keys.openpgp.org/about/faq#older-gnupg
[2]: https://build.opensuse.org/package/show/openSUSE:Factory/gpg2
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930665#10
[4]: https://dev.gnupg.org/T4393#133689