This needs to target the staging branch.

No problemo :) \\ edit oh whoops, wrong base. fixing in a second.

Rebased onto staging. Builds and works fine for me.

I tried to collect some background information which might help a possible reviewer. NOTE: I am by no means an expert on this topic. @Valodim: please correct me if I am wrong.

• This is needed in order to facilitate a switch to keys.openpgp.org which does not send any user-ids for unverified users.
• This does not solve existing issues when downloading poisoned certificates from SKS keyservers.
• Werner Koch is reluctant to merge this. After crawling through a lot of the discussions on dev.gnupg.org I do think I have found the reason why:

Re 3.: I am still unconvinced about the use cases for accepting keys without user-id. In contrast to pgp-2, gpg has always had the policy to allow only keys with a user-id and futher only with valid, ie. signed, user-ids. The reason for this is that properties of the key are carried in the self-signature of the user-id. It is possible to take them also from so-called direct-key-signatures, but we do not have much experience with that feature and thus I fear that this will have severe regressions to the ecosystem. RFC-4880 even requires the user id and the planned change in rfc4880bis is merely for a very limited use case on embedded devices where there is no space for a user-id.
-- Source

• Patch-state in other distributions (19. Feb. 2020):
  • Fedora included since 2.2.18-3 ( 04 Jan 2020 )
  • Debian
  • Gentoo
  • Arch Linux
  • Void Linux
• Personally this would have helped me a few days ago. Therefore, from a usability perspective I would like to see this merged. But I am a bit worried that this might have a possible security impact.

All of those points seem correct, thanks for writing them up :)

This is needed in order to facilitate a switch to keys.openpgp.org which does not send any user-ids for unverified users.

Correct. This is already the default in Nix since #63952, so even stable. Disclaimer: I maintain keys.openpgp.org.

I do think I have found the reason why:

The quoted argument is sound in itself, but slightly misses the point. I am still unconvinced about the use cases for accepting keys without user-id. - the patch doesn't allow importing keys without user ids per se, nor does it make an argument that this should be possible. It allows importing updates for keys that are already known, from key data that carries no user ids.

In a nutshell, a key typically consists of: primary key + subkeys + revocations + user ids. GnuPG checks for this structure on import. There is indeed a good argument not to import keys without user ids, since the user ids (or rather, their self-signatures) carry relevant metadata for the primary key. However, the subkeys and revocations can independently be checked for cryptographic integrity. For a key where a user id is already known, if we see a file that's "primary key + revocation + subkeys", the behavior this patch introduces is to merge the revocations and subkeys into the local store.

To put it differently, if you currently hand GnuPG a file with structure "primary key + revocation", the revocation will be ignored, unless there is also a valid user id on the data. Same for subkeys.

I can only speculate why Werner doesn't want to merge this patch. So far I have not seen a sound technical argument against the use case.

Patch-state in other distributions (19. Feb. 2020)

It's also in GPGTools for macOS, iinm.

Hi there -- i'm the most active GnuPG maintainer in debian. just wanted to weigh in here to corroborate @Valodim's analysis and the attached patches in case that's useful.

The default keyserver is used for gpg --refresh, which is typically used to retrieve revocation information and new subkeys. keys.openpgp.org is entirely capable of distributing those updates, but without the changes listed here, GnuPG will ignore those updates, even though they are cryptographically verifiable.

This change is an important one, and should be applied upstream. But given upstream's inexplicable delay, those of us who redistribute GnuPG are obliged to fix it for our users.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review-may-2019/3032/121