Page MenuHome GnuPG

auto-key-locate is annoying
Closed, ResolvedPublic

Description

As discussed offline recently, auto-key-locate with any network transport is
very annoying to use, because it constantly stalls the client while it accesses
the network. My suggestion is to queue any network operations. This means that
the key will not be available for the current operation, but it will (probably)
be available in the future. Ideally, we wouldn't fire and forget, but wait up
to, say, 50 milliseconds (see [1] for why this is reasonable), before putting
the operation in the background. For encrypting messages, this won't work, but
for verifying signatures, this behavior will present a desirable tradeoff for
many users.

Two immediately obvious approaches are:

  • When the network operation finishes, dirmngr then imports the key by calling

gpg --import to import the key into the keyring.

  • We store the result in a local DB. When we see the same query again, we

simply return the result to the caller.

[1] https://www.nngroup.com/articles/response-times-3-important-limits/

Event Timeline

The major trouble we have here is that dirmngr is not abale to detect network
failures. This is due to ADNS which keeps on trying to send UDP packets for 30
sesonds desipte a ENETUNREACH. I tried with a patched ADNS versions and did
not anymore suffer from these problems.

However, when a keyserver is not answering in time, there is indeed a problem.
A problem we may be able so solve with queuing the requests after a short
timeout. gpg already tells dirmngr that it is prepared for such a "soft
failure" but we need to implement this in dirmngr.

The whole thing is not new (except for ADNS) and has been with us since the
introduction of --auto-key-locate and --auto-key-retrive. WHich is a LONG time ago.

werner claimed this task.

Due to better working timeouts we have mostly soolved these problems,. Further keyservers are not anymore of great use these days.