FS#71078 - [gnupg] change default keyserver due to certificate expiration this month

Attached to Project: Arch Linux
Opened by A. Bosch (progandy) - Tuesday, 01 June 2021, 07:01 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 22 July 2021, 05:38 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

Description:

gnupg by default uses hkps://hkps.pool.sks-keyservers.net as the keyserver.
The last server in the pool will be lost on Fri, 25 Jun 2021 18:29:41 GMT with the expiration of its tls certificate.

The certificate will not be renewed:
> This service is deprecated. This means it is no longer maintained, and new HKPS certificates will not be issued. Service reliability should not be expected.
See: https://sks-keyservers.net/status/

One option is to use the unencrypted hkp pool or directly talk to one of the servers in the pool over tls. Many of them support hkps with a let's encrypt certificate.

The last server in the hkps pool is operated by fleetstreetops (pod02). They have a second server (pod01) with a let's encrypt certificate, switching to that would ensure continued keyserver operation while practically staying with the same server operators.

hkps://sks.pod01.fleetstreetops.com/

Other servers in the pool that do support hkps if used directly are:

hkps://keys.niif.hu
hkps://keyserver.insect.com
hkps://keywin.trifence.ch
hkps://pgp.net.nz
hkps://pgp.uni-mainz.de
hkps://pgpkeys.co.uk
hkps://pgpkeys.eu
hkps://pgpkeys.uk
hkps://sks.hnet.se
hkps://sks.pgpkeys.eu

hkps://pgp.lehigh.edu
hkps://keybath.trifence.ch

Additional info:
* gnupg 2.2.27-1
* Deprecation notice on https://sks-keyservers.net/ (certificate expired)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Thursday, 22 July 2021, 05:38 GMT
Reason for closing:  Fixed
Comment by loqs (loqs) - Tuesday, 01 June 2021, 22:35 GMT
What is upstream gnupg planning to do?
Comment by A. Bosch (progandy) - Wednesday, 02 June 2021, 06:24 GMT
I couldn't find any discussion about that in the gnupg mailing lists. There is also nothing in sks-devel, the only notice I could find is the expiration warning.

The sks server itself seems to be on the way out, new key servers appear to use hockeypuck now (a gpg keyserver written in go, with support for the sks sync protocol)
Comment by loqs (loqs) - Monday, 07 June 2021, 23:45 GMT
Both the attached patches based on similar patches used by Debian:
Use-keyserver.ubuntu.com-as-the-default-keyserver.patch changes the default keyserver. keyserver.ubuntu.com used as an example replacement for testing.
dirmngr-Only-use-SKS-pool-CA-for-SKS-pool.patch prevents the changed default from being rejected due to not being signed by the SKS root cert.

Patches are applied against 2.3.1 (for testing only release) as 2.2.27 currently fails to build from source.
   dirmngr-Only-use-SKS-pool-CA-... (0.6 KiB)
   Use-keyserver.ubuntu.com-as-t... (1.3 KiB)
Comment by A. Bosch (progandy) - Tuesday, 22 June 2021, 06:39 GMT
As of today, sks-keyservers.net has ceased to provide the round-robin-pool addresses.

https://sks-keyservers.net/
> Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all.

Recent discussion on sks-devel:
https://lists.nongnu.org/archive/html/sks-devel/2021-06/msg00001.html
Comment by loqs (loqs) - Sunday, 27 June 2021, 00:21 GMT
Suggestion from gnupg developer Werner Koch to not use keyservers for key discovery [1].

The use case of pacman-key already tries WKD before keyservers. For makepkg I believe WKD can not be used as key ID can not be mapped to email address without additional information.

Could support be added to makepkg to import the key from a file? Then the keyfile could be bundled with the PKGBUILD and avoid keyservers / WKD.

Removing the default keyserver would also require much more code changes reverting all the code that relies on there being a default server present and it is the SKS pool.

[1] https://lists.gnupg.org/pipermail/gnupg-devel/2021-June/034889.html
Comment by Christoph Reiter (lazka) - Sunday, 27 June 2021, 20:11 GMT
Upstream commit for switching the default keyserver: https://dev.gnupg.org/rG47c4e3e00a7ef55f954c14b3c237496e54a853c1
Comment by loqs (loqs) - Sunday, 27 June 2021, 21:11 GMT
[1] Does not apply cleanly to 2.2.28 due to the changes in [2]. Builds cleanly applying both patches [3].

[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=47c4e3e00a7ef55f954c14b3c237496e54a853c1
[2] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8ee4c8d1e0d7677d4f8b9538c12b32bb6393c2c5
[3] PKGBUILD.diff
Edit:
Corrected diff to be against trunk.
   PKGBUILD.diff (1.9 KiB)
   PKGBUILD.diff (1.9 KiB)
Comment by Mark Wagie (yochananmarqos) - Sunday, 27 June 2021, 21:34 GMT
Comment redacted.
Comment by Emil (xexaxo) - Tuesday, 29 June 2021, 16:08 GMT
Fwiw using the Ubuntu server does not work with out very own Linux package.

In particular the master/primary key gets imported, while verification fails.
Trying to fetch the subkey manually also fails with "rejected by import screener"

Edit: using keys.openpgp.org fails with "no user ID" as outlined in  FS#71362 

$ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys ABAF11C65A2970B130ABE3C479BE3E4300411886 647F28654894E3BD457199BE38DBBDC86092693E A2FF3A36AAA56654109064AB19802F8B0D70FC30
gpg: key 19802F8B0D70FC30: public key "Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>" imported
gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" imported
gpg: key 79BE3E4300411886: 1 duplicate signature removed
gpg: key 79BE3E4300411886: public key "Linus Torvalds <torvalds@kernel.org>" imported
gpg: Total number processed: 3
gpg: imported: 3

$ makepkg
...
==> Verifying source file signatures with gpg...
archlinux-linux git repo ... FAILED (unknown public key 3B94A80E50A477C7)


$ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 3B94A80E50A477C7
gpg: key 19802F8B0D70FC30: rejected by import screener
gpg: Total number processed: 1
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 June 2021, 16:39 GMT
From quickly googling around, that import screener error message appears to be saying "no I will not import an md5 signature no matter where you get it from".

Editing gpg.conf to allow md5 would help, but be insecure.
Comment by dkrm (dkrm) - Wednesday, 14 July 2021, 14:37 GMT
I think this bug report should be closed. The default keyserver used by GnuPG 2.2.29 is fixed upstream [1] and the current version in testing is the 2.2.29 [2].

[1] https://lists.gnupg.org/pipermail/gnupg-announce/2021q3/000461.html
[2] https://archlinux.org/packages/testing/x86_64/gnupg/

Loading...