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
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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.
Comment by loqs (loqs) - Saturday, 14 November 2020, 18:01 GMT
That would switch pacman-keyring's default keyserver to one which does not support third party signatures thus breaking Web Of Trust.
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.
Comment by Eli Schwartz (eschwartz) - Sunday, 15 November 2020, 02:54 GMT
This is a request for Arch to add functional patches to a package, which upstream deliberately marked as wontfix, in order to ADD NEW FEATURES.

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.

Loading...