Arch Linux

> 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 keyserver.ubuntu.com".

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

So, we know the sks-keyservers.net pool went offline. keys.gnupg.net did NOT go offline too, it was just another name for sks-keyservers.net
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.

https://pgp.mit.edu/ 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 keys.openpgp.org

> 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.

I believe we should close this ticket as "Won't implement", and wait for the openpgp.org group to figure out cross signature attestation so that their keyserver actually works as expected.

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 keys.openpgp.org going offline, pgp.mit.edu has been mostly ok - the last few days hkps://pgp.mit.edu is practically unreachable. The web UI is mostly ok though.
Using keyserver.ubuntu.com 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 - keys.openpgp.org 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.

If you recommend using ubuntu server then shouldn't it be used as build-in default as proposed in https://bugs.archlinux.org/task/71078

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.

@xexaxo,

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, openpgp.org is just as much of one) and your false point about pgp.mit.edu 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 pgp.mit.edu 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.)

Per  FS#71078  upstream GnuPG is going to resolve this by setting the default configure.ac keyserver to the ubuntu one.

> For https access keyserver.ubuntu.com 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.

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.

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.

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.

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 :-\

Those patches are not about removing cross signatures. They simply allow the usage of keys.openpgp.org.

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 keys.openpgp.org doesn't support them. Nevertheless, since a lot of tools set keys.openpgp.org as default keyserver (e.g. thunderbird), many of my contacts use keys.openpgp.org 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.

https://aur.archlinux.org/packages/gnupg-nouid-patch/

I would appreciate it, if those patches could be added to official packaging.

@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 keys.openpgp.org 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 keys.openpgp.org 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 keys.openpgp.org or communicating the necessity of granting permission for UIDs to be distributed to your peers?

[1] https://keys.openpgp.org/about/
[2] https://dev.gnupg.org/T4393#133695
[3] https://wiki.archlinux.org/title/GnuPG#Configuration_files

@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 keys.openpgp.org and missing from keyserver.ubuntu.com (+ 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).

@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 keys.openpgp.org.

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

> Anyway, I can say, without the patches I can't import *any* key from keys.openpgp.org.

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 keys.openpgp.org --recv-keys 2AC0A42EFB0B5CBC7A0402ED4DC95B6D7BE9892E
```

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

No. The problem is, that the users you are trying to communicate with did not give permission for their UID to be distributed by keys.openpgp.org.
This is not a problem of gnupg, but of GDPR allegedly preventing keys.openpgp.org to distribute the respective user's UIDs.

@dvzrv Indeed, thank you for the hint. That changes the impact of this issue drastically.

I think this can be closed. It's understandable why the Arch team does not want to carry downstream patches for important components such as GnuPG.

Plus as mentioned above - the key factors (being able to fetch given keys and (re)building Arch packages) have been mitigated/resolved.