Page MenuHome GnuPG

gnupg/dirmngr 2.1.17 fails on all keyserver operations
Closed, ResolvedPublic


(initial report: )

apologies; i'm no guru but i'll get you stack traces or whatever you need.

in version 2.1.17 of GnuPG/dirmngr, it appears that all keyserver operations
fail- even with a completely fresh GNUPGHOME.

original report as follows:

With the new update to GnuPG, I noticed that I was unable to retrieve, search,
or send keys, with all three actions resulting in a "no keyserver" error.
Reinitialized both my home directory and pacman .gnupg directories to ensure
this problem wasn't due to a configuration change but no dice. Rolling back to
GnuPG 2.1.16 immediately fixed the issue and I expect this is due to the new
resolver code and some weird interaction with Arch in particular. Even tried the
--standard-resolver option inside dirmngr.conf as mentioned in the changelog but
I just ended up getting "Unresolved Host".


[root@archdev ~]# ps auxf|egrep -E '(gpg|dirmngr)' | grep -v grep
[root@archdev ~]# rm -rf .gnupg
[root@archdev ~]# echo $GNUPGHOME

[root@archdev ~]# gpg --debug 1024 --keyserver
hkps:// --search-keys 9741E8AC
gpg: Note: no default option file '/root/.gnupg/gpg.conf'
gpg: enabled debug flags: ipc
gpg: directory '/root/.gnupg' created
gpg: new configuration file '/root/.gnupg/dirmngr.conf' created
gpg: new configuration file '/root/.gnupg/gpg.conf' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: DBG: chan_3 <- # Home: /root/.gnupg
gpg: DBG: chan_3 <- # Config: /root/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.17 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.17
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- 9741E8AC
gpg: DBG: chan_3 <- ERR 219 Server indicated a failure <Unspecified source>
gpg: error searching keyserver: Server indicated a failure
gpg: keyserver search failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: secmem usage: 0/32768 bytes in 0 blocks



Event Timeline

brents set Version to 2.1.17.
brents added a subscriber: brents.

I think that this bug is related to libdns. Unfortunately, it is not
reproducible for me.

Well, somehow related, I pushed my change:

commit d26c51825e2255fe58305cbc1cd74fa43f80d93e

In my environment, compiling with --disable-libdns or --standard-resolver at
runtime for dirmngr, it works fine. Before the fix, I confirmed that it failed
with --standard-resolver.

From my network, when I input:

KEYSERVER --clear hkps://

It results the error, because the network to the host is unreachable.
It is likely that it is an error of the network or the server.
And --standard-resolver thing is fixed by my commit.

would this patch[0] be acceptable for inclusion in branch?

note from patch composer:

Comment by Gaetan Bisson (vesath) - Friday, 23 December 2016, 07:22 GMT
So I came up with a fix that does two things:

  • fallback on the old, standard resolver code
  • if no SRV record is found, use CNAME (as expected but some weird error code

apparently broke this)

[0] fetched from

werner claimed this task.
werner removed a project: In Progress.
werner added a project: Unreleased.