Subject: gpg recv-key fails with no route to host

From: Craig Small <[email-masked]>
Date: Fri, 23 Nov 2018 10:04:15 +1100

Package: gpg
Version: 2.2.11-1
Severity: important

Hello GPG maintainers,
  It seems that gpg will not download keys anymore. I cannot even
download my own key from the Debian keyservers.

While not making the package entirely useless, it's pretty close.
Debugging didn't seem to show anything extra.

I think the GnuPG developers pride themselves on terrible error
messages, they may as well had said unknown error 113 for this one.

 - Craig

csmall@elmo:~$ gpg --keyserver keyring.debian.org --recv-key 0xdf50fea5
gpg: keyserver receive failed: No route to host
csmall@elmo:~$ ping keyring.debian.org
PING keyring.debian.org(kaufmann.debian.org
(2001:41b8:202:deb:1a1a:0:52c3:4b6b)) 56 data bytes
64 bytes from kaufmann.debian.org (2001:41b8:202:deb:1a1a:0:52c3:4b6b):
icmp_seq=1 ttl=44 time=344 ms
^C
--- keyring.debian.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 344.037/344.037/344.037/0.000 ms
csmall@elmo:~$ ping -4 keyring.debian.org
PING kaufmann.debian.org (82.195.75.107) 56(84) bytes of data.
64 bytes from kaufmann.debian.org (82.195.75.107): icmp_seq=1 ttl=46
time=350 ms
64 bytes from kaufmann.debian.org (82.195.75.107): icmp_seq=2 ttl=46
time=352 ms
^C
--- kaufmann.debian.org ping statistics ---
3 packets transmitted, 2 received, 33.3333% packet loss, time 89ms
rtt min/avg/max/mdev = 349.529/350.605/351.682/1.228 ms

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gpg depends on:
ii  gpgconf        2.2.11-1
ii  libassuan0     2.5.1-2
ii  libbz2-1.0     1.0.6-9
ii  libc6          2.27-8
ii  libgcrypt20    1.8.4-3
ii  libgpg-error0  1.32-3
ii  libreadline7   7.0-5
ii  libsqlite3-0   3.25.3-1
ii  zlib1g         1:1.2.11.dfsg-1

Versions of packages gpg recommends:
ii  gnupg  2.2.11-1

gpg suggests no packages.

-- no debconf information

---

From: Craig Small <[email-masked]>
Date: Fri, 23 Nov 2018 10:23:42 +1100

It appears dirmngr tries to lookup a SRV record and that's the no route to
host error.

---

From: Werner Koch <[email-masked]>
Date: Fri, 23 Nov 2018 11:47:37 +0100

> It appears dirmngr tries to lookup a SRV record and that's the no route to

Please put this into ~/.gnupg/dirmngr.conf 

--8<---------------cut here---------------start------------->8---
log-file /whatever
verbose
debug ipc,dns,network
--8<---------------cut here---------------end--------------->8---

and best try also with upstream or Sid and not the heavily patched
Debian version.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Craig Small <[email-masked]>
Date: Mon, 26 Nov 2018 08:22:09 +1100

It seems it needs the SRV record and fails wrong without it.
Checking on the same system looking up that SRV record I get the
expected NXDOMAIN error.

$ host -t srv _pgpkey-http._tcp.keyring.debian.org
Host _pgpkey-http._tcp.keyring.debian.org not found: 3(NXDOMAIN)

dirmngr log file:

2018-11-26 08:16:13 dirmngr[15805.0] certificate '/etc/ssl/certs/ca-certificates.crt' already cached
2018-11-26 08:16:13 dirmngr[15805.0] permanently loaded certificates: 136
2018-11-26 08:16:13 dirmngr[15805.0]     runtime cached certificates: 0
2018-11-26 08:16:13 dirmngr[15805.0]            trusted certificates: 136 (135,0,0,1)
2018-11-26 08:16:13 dirmngr[15805.6] handler for fd 6 started
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 -> # Home: /home/csmall/.gnupg
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 -> # Config: /home/csmall/.gnupg/dirmngr.conf
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 -> OK Dirmngr 2.2.11 at your service
2018-11-26 08:16:13 dirmngr[15805.6] connection from process 15804 (1000:1000)
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 <- GETINFO version
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 -> D 2.2.11
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 -> OK
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 <- KEYSERVER --clear hkp://keyring.debian.org
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 -> OK
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 <- KS_GET -- 0xDF50FEA5
2018-11-26 08:16:13 dirmngr[15805.6] DBG: dns: libdns initialized
2018-11-26 08:16:13 dirmngr[15805.6] DBG: dns: getsrv(_pgpkey-http._tcp.keyring.debian.org): No route to host
2018-11-26 08:16:13 dirmngr[15805.6] command 'KS_GET' failed: No route to host
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 -> ERR 167804970 No route to host <Dirmngr>
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 <- BYE
2018-11-26 08:16:13 dirmngr[15805.6] DBG: chan_6 -> OK closing connection
2018-11-26 08:16:13 dirmngr[15805.6] handler for fd 6 terminated
-- 
Craig Small               https://dropbear.xyz/     csmall at : enc.com.au
Debian GNU/Linux          https://www.debian.org/   csmall at : debian.org
Mastodon: @[email-masked]               Twitter: @smallsees  
GPG fingerprint:        5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

---

From: Werner Koch <[email-masked]>
Date: Mon, 26 Nov 2018 08:42:20 +0100

> Checking on the same system looking up that SRV record I get the

That seems to be a Debian specific problem; with a dirmngr started by
the gpg command, I get this with master (and pretty sure also with 2.2.11):

  DBG: chan_7 <- KEYSERVER --clear hkp://keyring.debian.org
  DBG: chan_7 -> OK
  DBG: chan_7 <- KS_GET -- 0xDF50FEA5
  DBG: dns: libdns initialized
  DBG: dns: getsrv(_pgpkey-http._tcp.keyring.debian.org) -> 0 records
  DBG: dns: resolve_dns_name(keyring.debian.org): Success
  resolve_dns_addr for 'keyring.debian.org': 'keyring.debian.org' [already known]
  resolve_dns_addr for 'keyring.debian.org': 'keyring.debian.org' [already known]
  DBG: dns: resolve_dns_name(keyring.debian.org): Success
  DBG: chan_7 -> S SOURCE http://keyring.debian.org:11371
  DBG: (20847 bytes sent via D lines not shown)

Can you please test with

  standard-resolver
  no-use-tor

in dirmngr.conf ?

---

From: Craig Small <[email-masked]>
Date: Mon, 26 Nov 2018 22:52:29 +1100

The standard-resolver option makes it work, how strange. I can see the
system trys to resolve the SRV record and then after that an A/AAAA record.

 - Craig

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 26 Nov 2018 18:25:14 -0500

> the gpg command, I get this with master (and pretty sure also with 2.2.11):

I don't see the problem on my local network when using 2.2.11-1 (that
is, including the debian-specific patches, and using dirmngr as launched
by the local user's systemd instance). 

I wouldn't be surprised if the problems about the specific network are
the cause here.

~/.gnupg/dirmngr.conf contains only:

    debug ipc,dns,network

And I ran the following two commands:

    systemctl --user stop dirmngr
    gpg-connect-agent --dirmngr 'KEYSERVER --clear hkp://keyring.debian.org' 'KS_GET -- 0xDF50FEA5' /bye

To get the logs, i ran:

    journalctl --since -10min --user-unit dirmngr.service

Nov 26 16:24:04 testhost systemd[1509]: Started GnuPG network certificate management daemon.
Nov 26 16:24:04 testhost dirmngr[32374]: dirmngr[32374]: enabled debug flags: ipc dns network
Nov 26 16:24:04 testhost dirmngr[32374]: permanently loaded certificates: 129
Nov 26 16:24:04 testhost dirmngr[32374]:     runtime cached certificates: 0
Nov 26 16:24:04 testhost dirmngr[32374]:            trusted certificates: 129 (128,0,0,1)
Nov 26 16:24:04 testhost dirmngr[32374]: handler for fd 5 started
Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 -> # Home: /home/dkg/.gnupg
Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 -> # Config: /home/dkg/.gnupg/dirmngr.conf
Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 -> OK Dirmngr 2.2.11 at your service
Nov 26 16:24:04 testhost dirmngr[32374]: connection from process 32373 (1000:1000)
Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 <- KEYSERVER --clear hkp://keyring.debian.org
Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 -> OK
Nov 26 16:24:04 testhost dirmngr[32374]: DBG: chan_5 <- KS_GET -- 0xDF50FEA5
Nov 26 16:24:04 testhost dirmngr[32374]: DBG: dns: libdns initialized (tor mode)
Nov 26 16:24:05 testhost dirmngr[32374]: DBG: dns: getsrv(_pgpkey-http._tcp.keyring.debian.org) -> 0 records
Nov 26 16:24:05 testhost dirmngr[32374]: DBG: dns: libdns initialized (tor mode)
Nov 26 16:24:06 testhost dirmngr[32374]: DBG: dns: resolve_dns_name(keyring.debian.org): Success
Nov 26 16:24:06 testhost dirmngr[32374]: resolve_dns_addr for 'keyring.debian.org': 'keyring.debian.org' [already known]
Nov 26 16:24:06 testhost dirmngr[32374]: number of system provided CAs: 128
Nov 26 16:24:06 testhost dirmngr[32374]: DBG: Using TLS library: GNUTLS 3.5.19
Nov 26 16:24:06 testhost dirmngr[32374]: DBG: http.c:connect_server: trying name='keyring.debian.org' port=11371
Nov 26 16:24:07 testhost dirmngr[32374]: DBG: dns: resolve_dns_name(keyring.debian.org): Success
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: http.c:1877:socket_new: object 0x00007f2b0c3490a0 for fd 6 created
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: http.c:request:
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: >> GET /pks/lookup?op=get&options=mr&search=0xDF50FEA5 HTTP/1.0\r\n
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: >> Host: keyring.debian.org:11371\r\n
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: http.c:request-header:
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: >> \r\n
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: chan_5 -> S PROGRESS tick ? 0 0
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: http.c:response:
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: >> HTTP/1.1 200 OK\r\n
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Date: Mon, 26 Nov 2018 21:24:08 GMT'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Server: Apache'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'X-Content-Type-Options: nosniff'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'X-Frame-Options: sameorigin'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Referrer-Policy: no-referrer'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'X-Xss-Protection: 1'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Vary: Accept-Encoding'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'X-Clacks-Overhead: GNU Terry Pratchett'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Connection: close'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: 'Content-Type: text/html; charset=ISO-8859-1'
Nov 26 16:24:08 testhost dirmngr[32374]: http.c:RESP: ''
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: chan_5 -> S SOURCE http://keyring.debian.org:11371
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: (20847 bytes sent via D lines not shown)
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: chan_5 -> OK
Nov 26 16:24:08 testhost dirmngr[32374]: DBG: chan_5 <- [eof]
Nov 26 16:24:08 testhost dirmngr[32374]: handler for fd 5 terminated

So i think this shows that it doesn't appear to be the debian packaging.
It looks to me like it has to do with the GnuPG-specific DNS client
code.  Can you suggest further debugging steps for the original
reporter, Werner?

        --dkg

PS I don't actually think of debian's dirmngr being "heavily-patched".
   The 3 patches that we carry in debian unstable are only related to
   the scheduler/wakeup events, which keep an idle dirmngr from
   consuming unnecesary battery.  They were deferred by Werner upstream
   a couple years ago in the thread starting with
   id:[email-masked] on gnupg-devel.

   I haven't seen any effect from those patches on DNS resolution, but
   if they do have some effect, i'd like to know about it!