FS#68626 - [gnupg] Add patches to properly support keys.openpgp.org
Attached to Project:
Arch Linux
Opened by Christian Kotte (ckotte) - Saturday, 14 November 2020, 17:40 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 15 November 2020, 02:57 GMT
Opened by Christian Kotte (ckotte) - Saturday, 14 November 2020, 17:40 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 15 November 2020, 02:57 GMT
|
Details
[gnupg] Add patches to properly support keys.openpgp.org
Description: Add patches to properly support keys.openpgp.org as Debian and GPGTools for macOS do already. Lots of keys cannot be retrieved properly with the current version. See below. Patches Debian are using: https://salsa.debian.org/debian/gnupg2/-/tree/debian/master/debian/patches/import-merge-without-userid (maybe even more patches are necessary) GnuPG upstream has not merged the patch so far. Maybe they don't want to do it: https://dev.gnupg.org/T4393 (optional) Add patches to use hkps://keys.openpgp.org as the default keyserver. See also: https://salsa.debian.org/debian/gnupg2/-/blob/debian/master/debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch Package version: 2.2.23-1 Steps to reproduce: Configure hkps://keys.openpgp.org Retrieve key gpg --recv-keys 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910 gpg: key 0xBB572E0E2D182910: no user ID gpg: Total number processed: 1 |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Sunday, 15 November 2020, 02:57 GMT
Reason for closing: Won't implement
Additional comments about closing: Severe violation of arch philosophy; we won't patch new downstream features into a package, nor will we apply patches upstream explicitly rejected.
You don't like it? Discuss it with upstream.
Arch will not be your bludgeon to express your disagreement with upstream and sidestep their development process.
Sunday, 15 November 2020, 02:57 GMT
Reason for closing: Won't implement
Additional comments about closing: Severe violation of arch philosophy; we won't patch new downstream features into a package, nor will we apply patches upstream explicitly rejected.
You don't like it? Discuss it with upstream.
Arch will not be your bludgeon to express your disagreement with upstream and sidestep their development process.
Admittedly as hkps://hkps.pool.sks-keyservers.net is so overloaded most queries are dropped it is just changing the nature of the breakage.
You would need to add a default keyserver for pacman-key that does support WOT, see also [1].
[1] https://bbs.archlinux.org/viewtopic.php?id=257836
Edit:
The above applies only to changing the default keyserver.
Arch does not patch software like this. Our patches are intended to backport upstream bugfixes before an official release (if they're deemed important enough and cause trouble for users) or fix building the software on a new userland. We don't patch in features. We definitely don't patch in features upstream explicitly disagrees with.
There is zero chance we will EVER accept this patch. It violates arch philosophy on so many levels.
Arch will not be your bludgeon to express your disagreement with upstream and sidestep their development process. You don't like it? Discuss it with them.
...
Also keys.openpgp.org is a deliberately crippled, nonstandard keyserver, which breaks distro tooling and doesn't deliver user expectations.
Personal opinion: keys.openpgp.org should not under any circumstances be used. But if you do use it, you must expect it to be broken until they figure out a sane solution to the problems they currently try to solve in insane ways.