Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#71362 - [gnupg] Consider merging "no user ID" fixes

Attached to Project: Arch Linux
Opened by Emil (xexaxo) - Friday, 25 June 2021, 18:24 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 25 June 2021, 18:58 GMT
Task Type General Gripe
Category Packages: Core
Status Assigned
Assigned To Lukas Fleischer (lfleischer)
David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No



Tl;Dr: Without said patches, gpg is borderline incapable of fetching public keys.

Many keyservers are going offline either due to the SKS vulnerability [1] or GDPR [2] requests. Earlier this week and went offline. seems to be working, while the SKS vuln. safe can lead to "no user ID" GPG errors.

MR was proposed upstream and sadly rejected Based on my understanding it was rejected because the server does not comply to the spec in the strictest sense. The overall consensus is that the fix brings no security concerns.

Debian has been carrying patches [3] for around 2 years now, since the issue itself is rather popular [4] and [5].

[2] "Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all."

Steps to reproduce:

$ gpg --keyserver hkps:// --recv-keys ABAF11C65A2970B130ABE3C479BE3E4300411886
gpg: key 79BE3E4300411886: no user ID
gpg: Total number processed: 1
This task depends upon

Comment by Eli Schwartz (eschwartz) - Friday, 25 June 2021, 18:49 GMT
> The overall consensus is that the fix brings no security concerns.

Did anyone ever suggest that was the problem? This sentence seems to be a red herring.

Arch has a "follow upstream" policy for a good reason, I see no benefit to acting in a manner incompatible with upstream, other OSes, and other distros "except for Debian", when the solution is so utterly trivial as "use".

We don't even really benefit from this! And certainly, we don't benefit "because the sks pool went offline".

So, we know the pool went offline. did NOT go offline too, it was just another name for
This is a legitimate problem, but since we must centralize on *something* as a consequence, a well known and stable one like the Ubuntu one seems reasonable. looks up to me, at least as much as it ever is... that keyserver has been slow or reporting errors for years, I've never heard anyone suggest using it with a straight face.

Back to

> Based on my understanding it was rejected because the server does not comply to the spec in the strictest sense.

That server does not distribute UIDs, unless the owner verifies it via email. It doesn't distribute cross signatures ever. Cross signatures are very important, especially in pacman.

This is not "the strictest sense".

IMNSHO we had good reason to avoid these patches before, and we continue to have good reason.
Comment by Eli Schwartz (eschwartz) - Friday, 25 June 2021, 18:52 GMT
I believe we should close this ticket as "Won't implement", and wait for the group to figure out cross signature attestation so that their keyserver actually works as expected.
Comment by Emil (xexaxo) - Saturday, 26 June 2021, 15:02 GMT
I suspect you didn't mean it as such, but the reply reads like I'm deliberately trying to is not to skew or sway people. There is a reason why I linked the topics - people are encouraged to follow the threads as they see fit.

Prior to going offline, has been mostly ok - the last few days hkps:// is practically unreachable. The web UI is mostly ok though.
Using is fine - that's why I listed it - but it seems like a single point of failure.

My goal is to avoid the panic if/when it becomes unreachable.

And yes, I'm not happy that Arch will have to carry patches - on the contrary, I even poked some Arch people to _try_ and send upstream the patches they've been carrying locally for 2 months now.

From the discussions linked, is seems that both parties have made their mind - will not UID for all the keys and GnuPG is unwilling to merge said patches.

So at the end of the day it will be the end users - and maintainers going through duplicate bug reports - who will suffer.
Comment by Michel Koss (MichelKoss1) - Saturday, 26 June 2021, 22:25 GMT
If you recommend using ubuntu server then shouldn't it be used as build-in default as proposed in

Those are another patches from debian however I think gnupg should have some working keyserver by default instead of providing broken version and require users to add working version themselves. The fact upstream is unable to provide something that works shouldn't be excuse for Arch.
Comment by Eli Schwartz (eschwartz) - Sunday, 27 June 2021, 20:47 GMT

You think you're not trying to skew people, but you're arguing in favor of one solution over the other, so inherently yes you are. So am I! We just disagree about our biases. And apparently about what words to use to describe "discussing one solution and advocating for it".

Anyway as far as I can tell you said nothing new -- I already responded to both your false point about "single source of failure" (again, is just as much of one) and your false point about being mostly okay (maybe it has been for you, but it's *legendary* for being unresponsive and I don't think I've ever used its web interface successfully without 6 gateway timeouts first, or ever used its hkp interface without 6 inscrutable gnupg tooling errors. If anything, my quick poke at the web interface just this second indicates has reached shocking degrees of unprecedented reliability -- it took an entire minute to load, but it responded successfully the first time. Wow. I still hate it though. 60 second response times aren't appropriate.)
Comment by Eli Schwartz (eschwartz) - Sunday, 27 June 2021, 20:49 GMT
Per  FS#71078  upstream GnuPG is going to resolve this by setting the default keyserver to the ubuntu one.

> For https access is now used because it can be expected that this server can stand the load from newer gnupg LTS versions.
> Note: that the default server will be changed again as soon as a new connected keyserver infrastructure has been established.
Comment by Emil (xexaxo) - Tuesday, 29 June 2021, 15:42 GMT
According to the Cambridge dictionary argue implies disrespectful, rude or loud - none of which apply to my tone here.
Similarly skew is to distort, usually by virtue of withholding information - also not really applicable.

I was looking for calm discussion with open-minded people. If that's not possible so be it.
Comment by Giancarlo Razzolini (grazzolini) - Tuesday, 29 June 2021, 16:15 GMT
This is not my package, but I'm also in favor or following upstream. Having said that, @eschwartz, let's try to be civil in the responses. @xexaxo, I understand a bug was opened upstream and it's closed with won't fix.
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 June 2021, 16:29 GMT
An argument is a position taken by one side in a debate.

"To skew or sway people" can mean a couple things, but in the context of both I I interpreted it as to prefer one side (a bias/lack of impartiality) and attempt to convince people of such...

You having pointed out your preferred definitions of the terms, I can... see how you might come to think that was an attack, but I have to say I still don't feel it was the most natural definition for the latter, and I'm genuinely lost why you'd choose that definition for the former.

EDIT: to be clear, it sounded to meike you were trying to say you were impartial.
Comment by Emil (xexaxo) - Tuesday, 29 June 2021, 18:09 GMT
Yes, I am partial - sorry should have made it clearer. AFAICT it is extremely rare to be impartial.

The point I'm trying to make is that I cannot find any other way to have things working _reliably_.
Not a fan of local patches, not a fan of going against upstream either but in the rarest of occasions, that is the only way :-\
Comment by Max Harmathy (kastanienaxt) - Tuesday, 01 February 2022, 08:36 GMT
Those patches are not about removing cross signatures. They simply allow the usage of

Debian also relies on PGP key and signatures a lot. And they have incorporated those patches.

I'm also a fan of cross signatures and I find it odd to say the least, that doesn't support them. Nevertheless, since a lot of tools set as default keyserver (e.g. thunderbird), many of my contacts use for distributing their keys. This issue prevented me from communicating with them a few times, until I stumbled over this report.

I just created an AUR package with the patches applied and it works for me now.

I would appreciate it, if those patches could be added to official packaging.
Comment by David Runge (dvzrv) - Thursday, 09 June 2022, 09:54 GMT
@xexaxo: Thanks for the report and the links to the upstream issues. After investigating this for a bit, it does indeed seem that adding these patches is rather detrimental to the package.

The core issue seems to be, that some certificates retrieved from some keyservers are not compatible with the OpenPGP spec (if the user does not give permission to have their UID be distributed, which is how does that [1]).
Carrying (and subsequently maintaining) a patch that fixes issues with integration with some of the existing keyserver infrastructure (which is actually down to the users choice of having their UID distributed or not) is outside of the scope of maintaining this package, especially given that upstream gnupg does not want to merge a patch that would allow import of keys without a UID [2] (this is what returns if a user does not give permission for their UID to be distributed).

Upstream follows the correct approach here IMHO: Without a UID, there is no way to safely verify a signature on a UID and there is also no way of verifying that a UID is actually tied to a given public key.

@kastanienaxt: Have you looked into configuring your gnupg [2] to use a keyserver different from or communicating the necessity of granting permission for UIDs to be distributed to your peers?

Comment by Emil (xexaxo) - Thursday, 09 June 2022, 15:49 GMT
@dvzrv must admit, that I'm not well versed on the details, so thanks for checking through.

Looking back, I didn't mention the secondary reason that brought me here:
Some of our packages reference GPG keys which are present on and missing from (+ vice-versa). That makes rebuilding of said packages, in an automated way, hard if not impossible.

Since then Allan has proposed bundling the GPG keys within the source package, which side-steps that problem. I just hope his works lands soon (tm).
Comment by Max Harmathy (kastanienaxt) - Friday, 10 June 2022, 09:19 GMT
@dvzrv I haven't looked into the technical details of the patches and why it was rejected upstream. Anyway, I can say, without the patches I can't import *any* key from

Configuring a different keyserver is not the problem. In essence, this issue prevents encrypted communication with any user of

Comment by David Runge (dvzrv) - Friday, 10 June 2022, 09:34 GMT
> Anyway, I can say, without the patches I can't import *any* key from

I don't think that is actually correct.
You can only not import the keys that users did not give their permissions for.

E.g., I can do the following just fine:

gpg --keyserver --recv-keys 2AC0A42EFB0B5CBC7A0402ED4DC95B6D7BE9892E

> Configuring a different keyserver is not the problem. In essence, this issue prevents encrypted communication with any user of

No. The problem is, that the users you are trying to communicate with did not give permission for their UID to be distributed by
This is not a problem of gnupg, but of GDPR allegedly preventing to distribute the respective user's UIDs.
Comment by Max Harmathy (kastanienaxt) - Friday, 10 June 2022, 10:53 GMT
@dvzrv Indeed, thank you for the hint. That changes the impact of this issue drastically.