Non-blocking connect for dirmngr

Daniel Kahn Gillmor dkg at
Thu Jun 8 21:55:43 CEST 2017

On Thu 2017-06-08 18:28:18 +0200, Werner Koch wrote:
> When using --auto-key-retrieve or --auto-key-locate to automagically
> retrieve keys from the Web Key Directory (WKD) or keyservers it often
> happens that a server does not respond timely.
> Keyservers may be down and dirmngr would then select another keyserver.
> However, it may take several minutes until the connect call returns an
> error.  Annoying.

thanks for working on fixing this, Werner!  It's definitely important if
GnuPG is going to be making these queries.

> Even more annoying are WKD queries to servers which don't support this
> service and - worse - don't run a web server at all at the expected
> address.  For example one of our core hackers has an address at
> Now when dirmngr want to lookup an address it tries
> and hangs (plain http redirects to and
> works).  After it times out the code tries the next server listed for
> that address, until that one times out as well.  Finally after 3 times
> the default timeout you get an error message back.  That can be 15
> minutes or more.  Clearly not acceptable.

Another approach could be "happy eyeballs" -- if the name resolves to 2
IP addresses, connect to both of them concurrently and take the first
connection that completes.  You wouldn't want to do this if there was a
hundred IP addresses, but there's probably a reasonable middle-ground
that gets you both resiliency when one host is down, and avoids flodding
the network.  perhaps up to 4 outstanding concurrent connections?  And
as they fail, if there are as-yet-untried addresses, they could launch

that'd allow you to keep a reasonable timeout so that sluggish servers
have a chance to respond, while not having responsive servers get stuck
behind sluggish servers if they exist.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170608/bc5517e2/attachment.sig>

More information about the Gnupg-devel mailing list