dirmngr should try the configured keyservers anyway even if they are all dead
Open, NormalPublic


if dirmngr is explicitly configured with a keyserver -- or if it is using the default configuration -- and its host table has *all* of the configured keyservers marked as dead, for whatever reason, then it refuses to make new requests, which causes gpg --search to fail (it tells the user to (use option --keyserver), which is a separate weirdness, see T4512).

marking keyservers as "known dead" is useful when selecting among a pool where some keyservers are dead but others are not. But if *all* keyservers are known dead, and the user is requesting a network connection anyway, dirmngr should go ahead and try one of the dead ones, rather than pre-emptively failing.


External Link
dkg created this task.May 14 2019, 12:54 AM
dkg added a comment.May 14 2019, 1:00 AM

This is particularly bad for users who have manually specified a given keyserver in dirmngr.conf, because even a transient failure in that keyserver will prevent them from any future keyserver requests until dirmngr decides that the "death" has worn off.

Most troublingly, this fatal failure mode might encourage some keyserver operators to try to hide transient failures to avoid this bad use case, which would make error signalling even harder to interpret.

werner triaged this task as Normal priority.
dkg added a comment.Thu, Oct 24, 5:39 PM

There is a growing bit of popular lore in the GnuPG community that "when keyserver operations fail, you solve that problem with killall dirmngr." I believe this suggestion is potentially damaging (the long-running daemon may be in the middle of operations for a client that you don't know about), but i suspect it is circulating as advice because it resolves the situation outlined in this ticket. For whatever ephemeral reason, dirmngr gets stuck, and fails to notice that this situation has resolved itself.

If we don't want users to ritualistically invoke killall dirmngr then dirmngr needs to be better about actively trying again.