Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
gnupg-devel at spodhuis.org
Tue Jul 13 22:09:25 CEST 2021
On 2021-07-13 at 18:26 +0200, Ingo Klöcker wrote:
> On Dienstag, 13. Juli 2021 10:15:17 CEST Bernhard Reiter wrote:
> > Does it make sense to change the list of servers behind
> > keys.gnupg.net as well?
> > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.
> > html "The keyserver hkp://keys.gnupg.net uses round robin DNS to give a
> > different keyserver each time you use it."
> This needs to be updated. DNS isn't used anymore. See comment in code:
GnuPG has many released versions, which various distributions are using,
which will still be using the public hostname.
Updating what the DNS points at will benefit many people just using the
defaults, with their old distribution. Not updating is not likely to
encourage them to update, it will just reinforce the perception that PGP
is broken and a different ecosystem should be used.
It's the classic dilemma, "product" or "service". The hostname is part
of a long-term service which needs to cater to more than the current
product. It's probably unfunded, but it's also just some DNS.
What it probably needs is a decent stable pool to point to, or something
else which keeps it from being a weekly task of asking the software
maintainers to update DNS yet again.
In case it helps: a decade ago, I wrote an SKS spider for building a
graph of all the available servers, after a while, I rewrote from Python
to Go, and that can be found at
<https://github.com/philpennock/sks_spider>; it was a weekend rewrite
and is not clean Go and is not a good example of the language, but if
anyone wants a basis for getting started with building a graph for
publishing DNS records, this one works.
I had DNS zone-building running via cron which pulled from the API
exposed by this code. I was first to implement a few features which led
Kristian to add/improve the "official" sks-keyservers DNS logic, but I
never tried to get anyone to use my hostnames and kept them on
deliberately annoying hostnames, so as to not split people: it was
friendly feature competition, not service usage competition.
So if anyone wants to start up a DNS pool which spiders and
auto-filters, etc, then the above might be a reasonable starting point;
and even if it's not, seeing the filtering logic might at least help you
figure out what to do differently.
More information about the Gnupg-devel