Page MenuHome GnuPG
Create Task
Maniphest T4163

hkps://hkps.pool.sks-keyservers.net has to many bad servers to be a good default
Open, NormalPublic
Actions

Description

I am not happy with the current default hkps://hkps.pool.sks-keyservers.net especially for GpgOL and Gpg4win.

Too often there are servers in there that do not respond or a very slow.

It's incredibly bad user experience if users are guided in "first steps" instructions to search the key of their recpients e.g. by Kleopatra and then they don't find it.

E.g.

(main) aheinecke@esus ~/d/m/s/gpgol> time gpg --homedir `mktemp -d` --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1
gpg: keybox '/tmp/tmp.az5DMTpbHW/pubring.kbx' created
gpg: keyserver receive failed: No data
gpg --homedir `mktemp -d` --keyserver hkps://hkps.pool.sks-keyservers.net    0.00s user 0.00s system 0% cpu 16.486 total

It is also the cause that I have just disabled "auto-key-retrieve" again in GpgOL again. Too often it just takes too long to fail (and we currently have no way to show contents before verification finishes).

I would propose to at least switch to the high availability keyserver pool, but I didn't see that it works with hkps.
Alternatively better quality control on the https pool.

Or as another alternative: Host a high quality keyserver through the GnuPG e.V. and use that as default.

Details

Version
master

Related Objects
Search...

Event Timeline

• aheinecke created this task.Oct 1 2018, 9:40 AM
kristianf added a comment.Oct 1 2018, 10:19 AM

hkps pool really should be the most responsive, and it already requires clustered only servers for a couple of weeks to try to increase the responsiveness. Experience has shown that any keyserver with less than 3 nodes in a cluster should not be used towards end-users. But do you have any more debugging output as to the problem at hand?

Several issues have historically made debugging somewhat interesting, one of which is the SRV record issue on cheap home routers which is tested for using e.g 8.8.8.8 as DNS server instead. Another thing making it difficult is cross-continent peering, hkps pool doesn't do any geolocation and is more focused on Europe than NA which might impact things.

• aheinecke claimed this task.Oct 1 2018, 10:23 AM
• aheinecke added a subscriber: • werner.

Ok. I was not aware that HKPS should already have the highest quality.

I'll try to run some more structured tests. My "feeling" is that "No Data" happens about 10% on Linux and 30% in my Windows VM's.
Werner just added in GnuPG output that shows which IP is used for a keyserver.

• aheinecke triaged this task as Normal priority.Oct 1 2018, 10:24 AM
• aheinecke mentioned this in T4165: Dirmngr: Ipv6 causes network failure if Ipv6 can't be reached.Oct 1 2018, 2:39 PM
• aheinecke added a subtask: T4165: Dirmngr: Ipv6 causes network failure if Ipv6 can't be reached.
• werner added a comment.Oct 2 2018, 8:50 AM

The problem is that the keyserver network is abused as free and
permanent data storage. We can't do much about it without larger
changes on the search capabilities of the keyservers. For more
information see the archives of the sks-devel list starting in July.

We should put it of the agenda od the Brussesl summit in 3 weeks. I
have a few ideas what we can do in gpg.

matheusmoreira added a subscriber: matheusmoreira.May 9 2019, 8:38 PM
wiktor-k added a subscriber: wiktor-k.Jun 28 2019, 2:31 PM
Valodim added a subscriber: Valodim.Jul 1 2019, 4:22 PM
Valodim added a comment.Jul 10 2019, 4:36 PM

We should put it of the agenda od the Brussesl summit in 3 weeks. I have a few ideas what we can do in gpg.

For the record: this was indeed on the agenda at the brussels meeting, in two separate sessions actually. Notes are in the GnuPG wiki, under "Session 2: SKS keyserver - Kristian Fiskerstrand" as well as the follow-up under "keys.openpgp.org + GDPR concerns".

• werner closed subtask T4165: Dirmngr: Ipv6 causes network failure if Ipv6 can't be reached as Resolved.Nov 25 2019, 10:17 PM
Valodim mentioned this in T4513: dirmngr should try the configured keyservers anyway even if they are all dead.Feb 19 2020, 6:43 PM
Valodim added a comment.Dec 4 2020, 1:07 PM

Perhaps of interest for this issue: the HKPS pool has consisted of only a single server for a couple of months now.

Valodim added a comment.Jan 28 2021, 11:17 AM

The last server of the HKPS pool dropped off for several hours yesterday, during which hkps.pool.sks-keyservers.net could not be resolved.

Valodim added a comment.Jun 21 2021, 11:50 PM

The sks pool is now officially gone.

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

https://sks-keyservers.net/overview-of-pools.php

tianon added a subscriber: tianon.Jun 22 2021, 5:00 PM