Page MenuHome GnuPG

hkps:// has to many bad servers to be a good default
Open, NormalPublic


I am not happy with the current default hkps:// 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.


(main) aheinecke@esus ~/d/m/s/gpgol> time gpg --homedir `mktemp -d` --keyserver hkps:// --recv-key 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1
gpg: keybox '/tmp/tmp.az5DMTpbHW/pubring.kbx' created
gpg: keyserver receive failed: No data
gpg --homedir `mktemp -d` --keyserver hkps://    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.



Event Timeline

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

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.

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 " + GDPR concerns".

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

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

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.