dirmngr: gpg: keyserver receive failed: No keyserver available
Open, NormalPublic

Description

The package versions all refer to Arch x86_64.
The issue is definitely caused by dirmngr. The version of the running dirmngr is what determines whether the bug manifests or not.

The command "gpg --recv-key <key>" fails with the following error:
gpg: keyserver receive failed: Server indicated a failure

The last package version working fine is 2.1.16-2.
All following versions including 2.1.21-1 are affected by the bug.

Steps to reproduce:

After switching to a different version of gnupg, it is necessary to run the command "killall dirmngr".

Remove the key if already exists:
gpg --delete-keys 647F28654894E3BD457199BE38DBBDC86092693E

Run the command:
gpg --recv-key 647F28654894E3BD457199BE38DBBDC86092693E

Expected output:
gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>" imported
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 2 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 2f, 0u
gpg: next trustdb check due at 2019-02-14
gpg: Total number processed: 1
gpg: imported: 1

Output on versions affected by the bug:
gpg: keyserver receive failed: Server indicated a failure

Details

Version
2.1.17 and later

Related Objects

ndr76 created this task.May 16 2017, 9:21 PM
ndr76 created this object in space S1 Public.
dkg added a subscriber: dkg.May 19 2017, 1:50 AM

I'm using 2.1.21-2 from the debian experimental build, and i'm not seeing this misbehavior.

how is dirmngr configured for you? what does the network activity look like?

Just as a remainder: unlike Arch, Debian has gnupg and dirmngr in 2 different packages. The bug is in dirmngr.

The file .gnupg/dirmngr.conf has the following lines:
keyserver hkp://jirk5u4osbsr34t5.onion
keyserver hkp://keys.gnupg.net

Commenting either of them, or both doesn't fix the problem.

The file .gnupg/gpg.conf is all commented lines.

This is the output with a higher debug level:

[andrea@hog ~]$ strace -f -e trace=network -s 10000 gpg --debug-level guru --recv-key 647F286[2/1976]
D457199BE38DBBDC86092693E
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
socket(AF_UNIX, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/gnupg/S.dirmngr"}, 32) = 0
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/andrea/.gnupg
gpg: DBG: chan_3 <- # Config: /home/andrea/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.21 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.21
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0x647F28654894E3BD457199BE38DBBDC86092693E
gpg: DBG: chan_3 <- ERR 167772346 No keyserver available <Dirmngr>
gpg: keyserver receive failed: No keyserver available
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0

outmix=0 getlvl1=0/0 getlvl2=0/0

gpg: secmem usage: 0/32768 bytes in 0 blocks
+++ exited with 2 +++

werner added a subscriber: werner.Jun 7 2017, 1:27 PM

Please add

debug ipc,network,dns
log-file /foo/bar/dirmngr.log

to dirmngr.conf. Kill dirmngr and run

gpg -v --recv-key 647F28654894E3BD457199BE38DBBDC86092693E

strace is not necessary.

ndr76 added a comment.Jun 7 2017, 2:01 PM

@werner I've done the changes you suggested. This is what I get in dirmngr.log:

2017-06-07 12:54:59 dirmngr[4344] listening on socket '/run/user/1000/gnupg/S.dirmngr'
2017-06-07 12:54:59 dirmngr[4345.0] permanently loaded certificates: 158
2017-06-07 12:54:59 dirmngr[4345.0] runtime cached certificates: 0
2017-06-07 12:54:59 dirmngr[4345.0] trusted certificates: 158 (157,0,0,1)
2017-06-07 12:55:00 dirmngr[4345.6] handler for fd 6 started
2017-06-07 12:55:00 dirmngr[4345.6] DBG: chan_6 -> # Home: /home/andrea/.gnupg
2017-06-07 12:55:00 dirmngr[4345.6] DBG: chan_6 -> # Config: /home/andrea/.gnupg/dirmngr.conf
2017-06-07 12:55:00 dirmngr[4345.6] DBG: chan_6 -> OK Dirmngr 2.1.21 at your service
2017-06-07 12:55:00 dirmngr[4345.6] connection from process 4342 (1000:1000)
2017-06-07 12:55:00 dirmngr[4345.6] DBG: chan_6 <- GETINFO version
2017-06-07 12:55:00 dirmngr[4345.6] DBG: chan_6 -> D 2.1.21
2017-06-07 12:55:00 dirmngr[4345.6] DBG: chan_6 -> OK
2017-06-07 12:55:00 dirmngr[4345.6] DBG: chan_6 <- KS_GET -- 0x647F28654894E3BD457199BE38DBBDC86092693E
2017-06-07 12:55:00 dirmngr[4345.6] DBG: dns: libdns initialized
2017-06-07 12:55:10 dirmngr[4345.6] DBG: dns: getsrv(_pgpkey-http._tcp.keys.gnupg.net): Server indicated a failure
2017-06-07 12:55:10 dirmngr[4345.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
2017-06-07 12:55:10 dirmngr[4345.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
2017-06-07 12:55:10 dirmngr[4345.6] DBG: chan_6 <- BYE
2017-06-07 12:55:10 dirmngr[4345.6] DBG: chan_6 -> OK closing connection
2017-06-07 12:55:10 dirmngr[4345.6] handler for fd 6 terminated

werner added a comment.Jun 7 2017, 3:03 PM

Problem with your DNS server We had a similar bug report here or on the ML. IIRC the DNS does not do what it is supposed to do. Need to lookup the details.

Workaround is to put

standard-resolver

into dirmngr.conf. Or to force the use of tor (option: use-tor)

werner triaged this task as Normal priority.Jun 7 2017, 3:04 PM
georg added a subscriber: georg.Feb 12 2018, 3:49 AM
gfa added a subscriber: gfa.May 24 2019, 10:03 AM