Here's a concrete example of how using PTR records gets things mixed up.

keyserver.stack.nl offers keyserver service on port 443.

It has an A record at 131.155.141.70.

But the ptr is to mud.stack.nl:

70.141.155.131.in-addr.arpa. 69674 IN PTR mud.stack.nl.

and the https SNI and HTTP Host: directives provide an entirely different
website depending on whether you access it with:

  https://mud.stack.nl/

or

  https://keyserver.stack.nl/

If you access it as https://hkps.pool.sks-keyservers.net/, you get the
"keyserver" view. But if you access it by the name in the PTR record
("mud.stack.nl") then you get the mud view (and a 404 on any /pks URLs)

Even more troubling is that dirmngr successfully connects to mud.stack.nl and
does the query, even though it is configured to only talk to
hkps.pool.sks-keyservers.net

This suggests that anyone able to spoof a PTR record to me can get my dirmngr to
send my potentially-sensitive keyserver queries to an entirely different webserver.

I've moved the discussion about the need for PTR over to
T2928

In this ticket, let's focus on what happens when Tor has the NoIPv6Traffic flag
set. How should dirmngr respond in that case?

I think if it gets a "permission denied" from its tor socket (or from any proxy)
when it's trying to connect to a host, it should treat that host as dead and
move to try next one. If dirmngr knows that it is using tor, and it knows that
the address it is trying is also IPv6, it could also log a message about the
IPv6Traffic flag.

does that seem like the right set of changes needed?

if you add NoIPv6Traffic to your torrc, and restart tor, can you replicate the
problem?

To answer your question:

  Can you explain why dirmngr does the DNS roundtrip lookup, mapping
  from the pool's A and AAAA addresses back to names?  It seems like
  it'd be a lot simpler (and faster, and less error-prone) to avoid
  the PTR lookups if we have the IP addresses already.

If it is a plain server and not a pool, looking up the PTR is
necessary to get the hostname for SNI and possible also for Host:
header.

For a pool we would not need the name because the already known name
of the pool is used for SNI. However, to find duplicate hosts in the
hosttable it is useful to have the hostname. We also return the
actual used hostname to gpg for information purposes and to eventually
store this with the key as meta info.

Yes, we could the PTR lookup of pools faster or in the background -
but for now a simple appraoch is better for debugging.

FWIW, I am using Libassuan 2.4.3 plus one portability fix for BSDs.

And here is a log when using

  keyserver hkp://oteiza.siccegge.de

in dirmngr.conf (and also use-tor) of course:

DBG: chan_7 -> OK Dirmngr 2.1.18-beta67 at your service
connection from process 24314 (1000:1000)
DBG: chan_7 <- keyserver --resolve --hosttable
DBG: dns: libdns initialized (tor mode)
DBG: dns: getsrv(_pgpkey-http._tcp.oteiza.siccegge.de) -> 0 records
DBG: dns: libdns initialized (tor mode)
DBG: dns: resolve_dns_name(oteiza.siccegge.de): Success
resolve_dns_addr for 'oteiza.siccegge.de': 'oteiza.siccegge.de' [already known]
DBG: dns: resolve_dns_addr(): Success
DBG: chan_7 -> S # http://oteiza.siccegge.de:11371
DBG: chan_7 -> S # hosttable (idx, ipv6, ipv4, dead, name, time):
DBG: chan_7 -> S # 0 6 oteiza.siccegge.de
v6=[2a01:4a0:59:1000:223:9eff:fe00:100f]
DBG: chan_7 -> OK
DBG: chan_7 <- [eof]
handler for fd 7 terminated
handler for fd 7 started
DBG: chan_7 -> # Home: /home/wk/.gnupg
DBG: chan_7 -> # Config: /home/wk/.gnupg/dirmngr.conf
DBG: chan_7 -> OK Dirmngr 2.1.18-beta67 at your service
connection from process 24325 (1000:1000)
DBG: chan_7 <- GETINFO version
DBG: chan_7 -> D 2.1.18-beta67
DBG: chan_7 -> OK
DBG: chan_7 <- KS_GET -- 0xDEADBEEF
number of system provided CAs: 173
DBG: http.c:connect_server: trying name='oteiza.siccegge.de' port=11371
DBG: dns: resolve_dns_name(oteiza.siccegge.de): Success
DBG: http.c:1706:socket_new: object 0x00007f1420453df0 for fd 8 created
DBG: http.c:request:
DBG: >> GET /pks/lookup?op=get&options=mr&search=0xDEADBEEF HTTP/1.0\r\n
DBG: >> Host: oteiza.siccegge.de:11371\r\n
DBG: http.c:request-header:
DBG: >> \r\n
DBG: chan_7 -> S PROGRESS tick ? 0 0
DBG: chan_7 -> S SOURCE http://oteiza.siccegge.de:11371
DBG: (27779 bytes sent via D lines not shown)
DBG: chan_7 -> OK

I tried this with and without my local v6 interface up; both are
obviously the same. Bote that in both cases my resolver is on the
local network and accessed via v4 - but it should not matter because
due to use-tor 8.8.8.8 is used anyway.

Even with the Tor from testing I am stil having the IPv6Traffic flag
in my torrc - I am not sure whether this is still required.

Using a configuration with only "use-tor" and debug options, and no
keyserver nor certificates defined I used

  gpg-connect-agent --dirmngr 'keyserver --resolve --hosttable' /bye

several times until I got oteiza.siccegge.de as keyserver:

DBG: chan_7 <- keyserver --resolve --hosttable
DBG: chan_7 -> S # https://oteiza.siccegge.de:443
DBG: chan_7 -> S # hosttable (idx, ipv6, ipv4, dead, name, time):
DBG: chan_7 -> S # 0 hkps.pool.sks-keyservers.net
DBG: chan_7 -> S # . hkps.pool.sks-keyservers.net
DBG: chan_7 -> S # . --> 2 10 6 4 9 5 8 7 1* 3
DBG: chan_7 -> S # 1 6 4 oteiza.siccegge.de
v6=[2a01:4a0:59:1000:223:9eff:fe00:100f] v4=92.43.111.21
DBG: chan_7 -> S # 2 6 4 bone.digitalis.org v6=[2a00:14b0:4200:3000:27::27]
v4=212.12.48.27
DBG: chan_7 -> S # 3 6 prod00.keyserver.dca.witopia.net
v6=[2606:9500:201:1::141]
DBG: chan_7 -> S # 4 6 4 gpg.NebrWesleyan.edu v6=[2606:1c00:2802::b]
v4=192.94.109.73
DBG: chan_7 -> S # 5 6 4 hufu.ki.iif.hu v6=[2001:738:0:600:216:3eff:fe02:42]
v4=193.224.163.43
DBG: chan_7 -> S # 6 6 4 gozer.rediris.es v6=[2001:720:418:caf1::8]
v4=130.206.1.8
DBG: chan_7 -> S # 7 6 4 mud.stack.nl v6=[2001:610:1108:5011::70]
v4=131.155.141.70
DBG: chan_7 -> S # 8 4 ip-209-135-211-141.ragingwire.net v4=209.135.211.141
DBG: chan_7 -> S # 9 4 host-37-191-238-78.lynet.no v4=37.191.238.78
DBG: chan_7 -> S # 10 4 cryptonomicon.mit.edu v4=18.9.60.141
DBG: chan_7 -> OK

and then "gpg --recv-key deadbeef":

DBG: chan_7 <- KS_GET -- 0xDEADBEEF
DBG: http.c:connect_server: trying name='oteiza.siccegge.de' port=443
DBG: dns: resolve_dns_name(oteiza.siccegge.de): Success
DBG: http.c:1706:socket_new: object 0x00007f5d5000bea0 for fd 9 created
DBG: http.c:request:
DBG: >> GET /pks/lookup?op=get&options=mr&search=0xDEADBEEF HTTP/1.0\r\n
DBG: >> Host: hkps.pool.sks-keyservers.net:443\r\n
DBG: http.c:request-header:
DBG: >> \r\n
DBG: chan_7 -> S PROGRESS tick ? 0 0
DBG: chan_7 -> S SOURCE https://oteiza.siccegge.de:443
DBG: (27779 bytes sent via D lines not shown)

I did my test with tor 2.5.12-4 (jessie). I will ungrade to testing now and redo.

here's the example run from my modified reproducer script that focuses on
oteiza.siccegge.de:

gpg: keybox '/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/pubring.kbx' created
gpg: keyserver receive failed: Permission denied
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 6 oteiza.siccegge.de v6=[2a01:4a0:59:1000:223:9eff:fe00:100f]
OK
2017-01-18 03:19:00 dirmngr[30881] listening on socket
'/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/S.dirmngr'
2017-01-18 03:19:00 dirmngr[30882.0] permanently loaded certificates: 0
2017-01-18 03:19:00 dirmngr[30882.0] runtime cached certificates: 0
2017-01-18 03:19:00 dirmngr[30882.0] failed to open cache dir file
'/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/crls.d/DIR.txt': No such file or directory
2017-01-18 03:19:00 dirmngr[30882.0] creating directory
'/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/crls.d'
2017-01-18 03:19:00 dirmngr[30882.0] new cache dir file
'/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/crls.d/DIR.txt' created
2017-01-18 03:19:01 dirmngr[30882.6] handler for fd 6 started
2017-01-18 03:19:01 dirmngr[30882.6] connection from process 30879 (1000:1000)
2017-01-18 03:19:01 dirmngr[30882.6] DBG: dns: libdns initialized (tor mode)
2017-01-18 03:19:02 dirmngr[30882.6] DBG: dns:
getsrv(_pgpkey-http._tcp.oteiza.siccegge.de) -> 0 records
2017-01-18 03:19:02 dirmngr[30882.6] DBG: dns: libdns initialized (tor mode)
2017-01-18 03:19:03 dirmngr[30882.6] DBG: dns:
resolve_dns_name(oteiza.siccegge.de): Success
2017-01-18 03:19:03 dirmngr[30882.6] resolve_dns_addr for 'oteiza.siccegge.de':
'oteiza.siccegge.de' [already known]
2017-01-18 03:19:03 dirmngr[30882.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 03:19:03 dirmngr[30882.6] number of system provided CAs: 142
2017-01-18 03:19:03 dirmngr[30882.6] DBG: http.c:connect_server: trying
name='oteiza.siccegge.de' port=11371
2017-01-18 03:19:05 dirmngr[30882.6] DBG: dns:
resolve_dns_name(oteiza.siccegge.de): Success
2017-01-18 03:19:05 dirmngr[30882.6] can't connect to 'oteiza.siccegge.de':
Permission denied
2017-01-18 03:19:05 dirmngr[30882.6] error connecting to
'http://oteiza.siccegge.de:11371': Permission denied
2017-01-18 03:19:05 dirmngr[30882.6] command 'KS_GET' failed: Permission denied
2017-01-18 03:19:05 dirmngr[30882.6] handler for fd 6 terminated
2017-01-18 03:19:05 dirmngr[30882.6] handler for fd 6 started
2017-01-18 03:19:05 dirmngr[30882.6] connection from process 30921 (1000:1000)
2017-01-18 03:19:05 dirmngr[30882.6] handler for fd 6 terminated

fwiw, i'm seeing fewer errors with this version than i was before, perhaps
because we're addressing servers via tor by name instead of by IP address, which
means that we're not tickling the IPv6 issue quite as often?

The failure with oteiza.siccegge.de might actually just be the IPv6 issue
itself, since there is no IPv4 address for it. I can actually force the issue
if i just add the following line to the dirmngr.conf generated in my reproducer
script:

    keyserver hkp://oteiza.siccegge.de

but of course it's a faster failure, because there isn't a dozen DNS A->PTR
round-trips.

Can you explain why dirmngr does the DNS roundtrip lookup, mapping from the
pool's A and AAAA addresses back to names? It seems like it'd be a lot simpler
(and faster, and less error-prone) to avoid the PTR lookups if we have the IP
addresses already.

I note here that the "oteiza.siccegge.de" domain name might be supplied by PTR
records for both its v4 and v6 addresses, and it appears to have a AAAA record,
but it doesn't have any *forward* A record.

I'm baffled by the fact that you're not seeing these errors, and not sure what
to do about it. What version of tor are you running? how is it configured?

i'm running the stock debian tor package, version 0.2.9.8-2.

I've tried with the latest patches and i still see failures :(

gpg: keybox '/home/dkg/tmp/tmp.nchsng7MNY/gpg/pubring.kbx' created
gpg: keyserver receive failed: Permission denied
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
S # . hkps.pool.sks-keyservers.net
S # . --> 9 11 6 4 10 5 7 8 2* 3 1
S # 1 6 4 sks.spodhuis.org v6=[2a02:898:31:0:48:4558:73:6b73] v4=94.142.242.225
S # 2 6 4 oteiza.siccegge.de v6=[2a01:4a0:59:1000:223:9eff:fe00:100f]
v4=92.43.111.21
S # 3 6 prod00.keyserver.dca.witopia.net v6=[2606:9500:201:1::141]
S # 4 6 4 gpg.NebrWesleyan.edu v6=[2606:1c00:2802::b] v4=192.94.109.73
S # 5 6 4 d hufu.ki.iif.hu v6=[2001:738:0:600:216:3eff:fe02:42]
v4=193.224.163.43 (1s)
S # 6 6 4 gozer.rediris.es v6=[2001:720:418:caf1::8] v4=130.206.1.8
S # 7 4 ip-209-135-211-141.ragingwire.net v4=209.135.211.141
S # 8 4 mud.stack.nl v4=131.155.141.70
S # 9 4 ams.sks.heypete.com v4=51.15.53.138
S # 10 4 host-37-191-238-78.lynet.no v4=37.191.238.78
S # 11 4 cryptonomicon.mit.edu v4=18.9.60.141
OK
2017-01-18 02:56:23 dirmngr[9098] listening on socket
'/home/dkg/tmp/tmp.nchsng7MNY/gpg/S.dirmngr'
2017-01-18 02:56:23 dirmngr[9099.0] permanently loaded certificates: 0
2017-01-18 02:56:23 dirmngr[9099.0] runtime cached certificates: 0
2017-01-18 02:56:23 dirmngr[9099.0] failed to open cache dir file
'/home/dkg/tmp/tmp.nchsng7MNY/gpg/crls.d/DIR.txt': No such file or directory
2017-01-18 02:56:23 dirmngr[9099.0] creating directory
'/home/dkg/tmp/tmp.nchsng7MNY/gpg/crls.d'
2017-01-18 02:56:23 dirmngr[9099.0] new cache dir file
'/home/dkg/tmp/tmp.nchsng7MNY/gpg/crls.d/DIR.txt' created
2017-01-18 02:56:24 dirmngr[9099.6] handler for fd 6 started
2017-01-18 02:56:24 dirmngr[9099.6] connection from process 9096 (1000:1000)
2017-01-18 02:56:24 dirmngr[9099.6] DBG: dns: libdns initialized (tor mode)
2017-01-18 02:56:25 dirmngr[9099.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
2017-01-18 02:56:25 dirmngr[9099.6] DBG: dns: libdns initialized (tor mode)
2017-01-18 02:56:27 dirmngr[9099.6] DBG: dns:
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
2017-01-18 02:56:28 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:28 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'sks.spodhuis.org'
2017-01-18 02:56:28 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:29 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:29 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'oteiza.siccegge.de'
2017-01-18 02:56:29 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:29 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:29 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'prod00.keyserver.dca.witopia.net'
2017-01-18 02:56:29 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:30 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:30 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'gpg.NebrWesleyan.edu'
2017-01-18 02:56:30 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:31 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): No name
2017-01-18 02:56:31 dirmngr[9099.6] resolve_dns_addr failed while checking
'hkps.pool.sks-keyservers.net': No name
2017-01-18 02:56:32 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:32 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'hufu.ki.iif.hu'
2017-01-18 02:56:32 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:33 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:33 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'gozer.rediris.es'
2017-01-18 02:56:33 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:34 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Connection
closed in DNS
2017-01-18 02:56:34 dirmngr[9099.6] resolve_dns_addr failed while checking
'hkps.pool.sks-keyservers.net': Connection closed in DNS
2017-01-18 02:56:35 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:35 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'ip-209-135-211-141.ragingwire.net'
2017-01-18 02:56:35 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:36 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:36 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'hufu.ki.iif.hu' [already known]
2017-01-18 02:56:36 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:37 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:37 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'gpg.NebrWesleyan.edu' [already known]
2017-01-18 02:56:37 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:38 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:38 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'mud.stack.nl'
2017-01-18 02:56:38 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:38 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:38 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'gozer.rediris.es' [already known]
2017-01-18 02:56:38 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:39 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:39 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'sks.spodhuis.org' [already known]
2017-01-18 02:56:39 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:40 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:40 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'oteiza.siccegge.de' [already known]
2017-01-18 02:56:40 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:41 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:41 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'ams.sks.heypete.com'
2017-01-18 02:56:41 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:41 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:41 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'host-37-191-238-78.lynet.no'
2017-01-18 02:56:41 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:42 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:42 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'cryptonomicon.mit.edu'
2017-01-18 02:56:42 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:42 dirmngr[9099.6] DBG: http.c:connect_server: trying
name='hufu.ki.iif.hu' port=443
2017-01-18 02:56:45 dirmngr[9099.6] DBG: dns: resolve_dns_name(hufu.ki.iif.hu):
Connection closed in DNS
2017-01-18 02:56:45 dirmngr[9099.6] resolving 'hufu.ki.iif.hu' failed:
Connection closed in DNS
2017-01-18 02:56:45 dirmngr[9099.6] can't connect to 'hufu.ki.iif.hu': host not
found
2017-01-18 02:56:45 dirmngr[9099.6] error connecting to
'https://hufu.ki.iif.hu:443': Unknown host
2017-01-18 02:56:45 dirmngr[9099.6] marking host 'hufu.ki.iif.hu' as dead
2017-01-18 02:56:45 dirmngr[9099.6] DBG: http.c:connect_server: trying
name='oteiza.siccegge.de' port=443
2017-01-18 02:56:46 dirmngr[9099.6] DBG: dns:
resolve_dns_name(oteiza.siccegge.de): Success
2017-01-18 02:56:46 dirmngr[9099.6] can't connect to 'oteiza.siccegge.de':
Permission denied
2017-01-18 02:56:46 dirmngr[9099.6] error connecting to
'https://oteiza.siccegge.de:443': Permission denied
2017-01-18 02:56:46 dirmngr[9099.6] command 'KS_GET' failed: Permission denied
2017-01-18 02:56:46 dirmngr[9099.6] handler for fd 6 terminated
2017-01-18 02:56:46 dirmngr[9099.6] handler for fd 6 started
2017-01-18 02:56:46 dirmngr[9099.6] connection from process 9101 (1000:1000)
2017-01-18 02:56:46 dirmngr[9099.6] handler for fd 6 terminated

Thanks for the dumps. I was not able to get the permission denied errors. The
ENETDOWN errors on my site where due to a IPv6 not being enabled for Tor (during
most of my older tests I used the Torbrowser).

Anyway, With the patches from today, things are working much better now.
Please give it a try.

gpg: keybox '/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/pubring.kbx' created
gpg: /home/dkg/tmp/tmp.0Ew9D45cz7/gpg/trustdb.gpg: trustdb created
gpg: key 7638D0442B90D010: public key "Debian Archive Automatic Signing Key
(8/jessie) <ftpmaster@debian.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
S # . hkps.pool.sks-keyservers.net
S # . --> 15 14 13 12 11 10 19 18* 17 16 9 8 7 6 5 4 3 2 1
S # 1 6 [2a02:898:31:0:48:4558:73:6b73]
S # 2 6 [2a01:4a0:59:1000:223:9eff:fe00:100f]
S # 3 6 [2a00:14b0:4200:3000:27::27]
S # 4 6 [2606:9500:201:1::141]
S # 5 6 [2606:1c00:2802::b]
S # 6 6 [2001:bc8:4700:2300::10:f15]
S # 7 6 [2001:bc8:2515::1]
S # 8 6 [2001:720:418:caf1::8]
S # 9 6 [2001:470:1:116::6]
S # 10 4 216.66.15.2
S # 11 4 212.12.48.27
S # 12 4 209.135.211.141
S # 13 4 192.94.109.73
S # 14 4 163.172.29.20
S # 15 4 130.206.1.8
S # 16 4 94.142.242.225
S # 17 4 92.43.111.21
S # 18 4 51.15.53.138
S # 19 4 37.191.238.78
OK
2017-01-12 11:35:25 dirmngr[833] listening on socket
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/S.dirmngr'
2017-01-12 11:35:25 dirmngr[834.0] permanently loaded certificates: 0
2017-01-12 11:35:25 dirmngr[834.0] runtime cached certificates: 0
2017-01-12 11:35:25 dirmngr[834.0] failed to open cache dir file
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:35:25 dirmngr[834.0] creating directory
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d'
2017-01-12 11:35:25 dirmngr[834.0] new cache dir file
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d/DIR.txt' created
2017-01-12 11:35:26 dirmngr[834.6] handler for fd 6 started
2017-01-12 11:35:26 dirmngr[834.6] connection from process 831 (1000:1000)
2017-01-12 11:35:26 dirmngr[834.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:35:27 dirmngr[834.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
2017-01-12 11:35:27 dirmngr[834.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:35:28 dirmngr[834.6] DBG: dns:
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a02:898:31:0:48:4558:73:6b73]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a01:4a0:59:1000:223:9eff:fe00:100f]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a00:14b0:4200:3000:27::27]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:9500:201:1::141]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:2515::1]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:720:418:caf1::8]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '216.66.15.2'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '212.12.48.27'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '209.135.211.141'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '192.94.109.73'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '163.172.29.20'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '130.206.1.8'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '94.142.242.225'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '92.43.111.21'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '51.15.53.138'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '37.191.238.78'
2017-01-12 11:35:28 dirmngr[834.6] DBG: http.c:connect_server: trying
name='51.15.53.138' port=443
2017-01-12 11:35:28 dirmngr[834.6] DBG: dns: resolve_dns_name(51.15.53.138): Success
2017-01-12 11:35:31 dirmngr[834.6] DBG: http.c:1706:socket_new: object
0x00007f57e400a5d0 for fd 8 created
2017-01-12 11:35:34 dirmngr[834.6] DBG: http.c:request:
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> GET
/pks/lookup?op=get&options=mr&search=0x126C0D24BD8A2942CC7DF8AC7638D0442B90D010
HTTP/1.0\r\n
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> Host:
hkps.pool.sks-keyservers.net:443\r\n
2017-01-12 11:35:34 dirmngr[834.6] DBG: http.c:request-header:
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> \r\n
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 terminated
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 started
2017-01-12 11:35:37 dirmngr[834.6] connection from process 841 (1000:1000)
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 terminated

gpg: keybox '/home/dkg/tmp/tmp.swbfPRERsO/gpg/pubring.kbx' created
gpg: keyserver receive failed: Server indicated a failure
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
OK
2017-01-12 11:36:01 dirmngr[851] listening on socket
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/S.dirmngr'
2017-01-12 11:36:01 dirmngr[852.0] permanently loaded certificates: 0
2017-01-12 11:36:01 dirmngr[852.0] runtime cached certificates: 0
2017-01-12 11:36:01 dirmngr[852.0] failed to open cache dir file
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:36:01 dirmngr[852.0] creating directory
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d'
2017-01-12 11:36:01 dirmngr[852.0] new cache dir file
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d/DIR.txt' created
2017-01-12 11:36:02 dirmngr[852.6] handler for fd 6 started
2017-01-12 11:36:02 dirmngr[852.6] connection from process 849 (1000:1000)
2017-01-12 11:36:02 dirmngr[852.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:12 dirmngr[852.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net): Server indicated a failure
2017-01-12 11:36:12 dirmngr[852.6] command 'KS_GET' failed: Server indicated a
failure <Unspecified source>
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 terminated
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 started
2017-01-12 11:36:12 dirmngr[852.6] connection from process 854 (1000:1000)
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 terminated

gpg: keybox '/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/pubring.kbx' created
gpg: keyserver receive failed: Permission denied
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
S # . hkps.pool.sks-keyservers.net
S # . --> 15 14 13 12 11 10 19 18 17 16 9 8 7 6 5 4 3 2* 1
S # 1 6 [2a02:898:31:0:48:4558:73:6b73]
S # 2 6 [2a01:4a0:59:1000:223:9eff:fe00:100f]
S # 3 6 [2a00:14b0:4200:3000:27::27]
S # 4 6 [2606:9500:201:1::141]
S # 5 6 [2606:1c00:2802::b]
S # 6 6 [2001:bc8:4700:2300::10:f15]
S # 7 6 [2001:bc8:2515::1]
S # 8 6 [2001:720:418:caf1::8]
S # 9 6 [2001:470:1:116::6]
S # 10 4 216.66.15.2
S # 11 4 212.12.48.27
S # 12 4 209.135.211.141
S # 13 4 192.94.109.73
S # 14 4 163.172.29.20
S # 15 4 130.206.1.8
S # 16 4 94.142.242.225
S # 17 4 92.43.111.21
S # 18 4 51.15.53.138
S # 19 4 37.191.238.78
OK
2017-01-12 11:36:23 dirmngr[866] listening on socket
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/S.dirmngr'
2017-01-12 11:36:23 dirmngr[867.0] permanently loaded certificates: 0
2017-01-12 11:36:23 dirmngr[867.0] runtime cached certificates: 0
2017-01-12 11:36:23 dirmngr[867.0] failed to open cache dir file
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:36:23 dirmngr[867.0] creating directory
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d'
2017-01-12 11:36:23 dirmngr[867.0] new cache dir file
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d/DIR.txt' created
2017-01-12 11:36:24 dirmngr[867.6] handler for fd 6 started
2017-01-12 11:36:24 dirmngr[867.6] connection from process 864 (1000:1000)
2017-01-12 11:36:24 dirmngr[867.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:26 dirmngr[867.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
2017-01-12 11:36:26 dirmngr[867.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:27 dirmngr[867.6] DBG: dns:
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a02:898:31:0:48:4558:73:6b73]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a01:4a0:59:1000:223:9eff:fe00:100f]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a00:14b0:4200:3000:27::27]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:9500:201:1::141]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:2515::1]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:720:418:caf1::8]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '216.66.15.2'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '212.12.48.27'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '209.135.211.141'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '192.94.109.73'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '163.172.29.20'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '130.206.1.8'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '94.142.242.225'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '92.43.111.21'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '51.15.53.138'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '37.191.238.78'
2017-01-12 11:36:27 dirmngr[867.6] DBG: http.c:connect_server: trying
name='2a01:4a0:59:1000:223:9eff:fe00:100f' port=443
2017-01-12 11:36:27 dirmngr[867.6] DBG: dns:
resolve_dns_name(2a01:4a0:59:1000:223:9eff:fe00:100f): Success
2017-01-12 11:36:27 dirmngr[867.6] can't connect to
'2a01:4a0:59:1000:223:9eff:fe00:100f': Permission denied
2017-01-12 11:36:27 dirmngr[867.6] error connecting to
'https://[2a01:4a0:59:1000:223:9eff:fe00:100f]:443': Permission denied
2017-01-12 11:36:27 dirmngr[867.6] command 'KS_GET' failed: Permission denied
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 terminated
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 started
2017-01-12 11:36:27 dirmngr[867.6] connection from process 869 (1000:1000)
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 terminated

Here's the reproducer script i'm using:

--------

#!/bin/bash

WORKDIR=$(mktemp -d)
export GNUPGHOME="$WORKDIR/gpg"
mkdir -p -m 0700 "$GNUPGHOME"
cat > "$GNUPGHOME/dirmngr.conf" <<EOF
debug dns,network
verbose
use-tor
log-file $WORKDIR/dirmngr.log
EOF

gpg --recv 126C0D24BD8A2942CC7DF8AC7638D0442B90D010

gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye

cat "$WORKDIR/dirmngr.log"

rm -rf "$WORKDIR"

I just ran it three times in a row, and i got three different results, which
i'll paste as separate messages for easier visibility.

Can you run dirmngr with

debug dns,network
verbose

I don't think that gnutls debug is required.

They don't solve the bug for me, unfortunately. with those patches applied, i
now get "permission denied" errors:

an 11 15:57:18 alice dirmngr[20203]: DBG: gnutls:L3: ASSERT:
mpi.c[_gnutls_x509_read_uint]:246
Jan 11 15:57:18 alice dirmngr[20203]: DBG: gnutls:L5: REC[0x7f07c0008640]:
Allocating epoch #0
Jan 11 15:57:18 alice dirmngr[20203]: can't connect to
'2a02:898:31:0:48:4558:73:6b73': Permission denied
Jan 11 15:57:18 alice dirmngr[20203]: error connecting to
'https://[2a02:898:31:0:48:4558:73:6b73]:443': Permission denied

which also don't mark the IPv6 address as dead, so they're effectively permanent
until i clear them out.

As a workaround, i've been clearing out all IPv6 addresses with this terrible hack:

0 dkg@alice:~$ cat bin/dirmngr-flush-ipv6
#!/bin/bash

drop all IPv6 keyservers from dirmngr:

gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye |\

awk '/\[.*:.*\]/{ print "keyserver --dead " $5 } ' |\
gpg-connect-agent --dirmngr

0 dkg@alice:~$

I just pushed two patches:
76fb2fe dirmngr: Mark hosts dead on ENETDOWN.
09aeac4 dirmngr: Fix Tor access for v6 addresses.
which should solve this bug.

The reason why we see an EINVAL for a v6 address is that
we create the socket for AF_INET6 but then use that very socket with AF_INET to
sonnect to the socks5 proxy. Cleary a socket for v6 can't be used to connect to
a v4 address.

In 2.1 --quit is honored here

I was wrong about Tor and IPv6 -- Tor has had IPv6 support for years, so
something else is wrong...

Fixed in 3c7d6a1769ed6cc90d86247a814a0dce341512a3.

Thank you for your excellent bug report!

I can reproduce the problem with current git master. Using my regular homedir /
certificates. I was having that for some time now but did not notice as I
thought it was a bug in using old kmail with 2.1 and I rarely use S/MIME. For me
KMail always showed "encryption failed" for S/MIME but the pinentry came up. I
entered my pin and hit sent again and it worked because the agent had cached my
passphrase and pinentry would not come up ;-)

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x000000000040fc65 in gpgsm_proxy_pinentry_notify (ctrl=ctrl@entry=0x1,

line=line@entry=0x68f548 "PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24") at

../../sm/server.c:1492
1492 if (!ctrl || !ctrl->server_local
(gdb) bt
#0 0x000000000040fc65 in gpgsm_proxy_pinentry_notify (ctrl=ctrl@entry=0x1,

line=line@entry=0x68f548 "PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24") at

../../sm/server.c:1492
#1 0x00000000004102da in default_inq_cb (opaque=0x7fffffffd990, line=0x68f548
"PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24")

at ../../sm/call-agent.c:197

#2 0x00007ffff747663c in assuan_transact (ctx=0x68f3f0, command=<optimized
out>, data_cb=0x443080 <put_membuf_cb>,

data_cb_arg=0x7fffffffd9a0, inquire_cb=0x4102b0 <default_inq_cb>,

inquire_cb_arg=0x7fffffffd990, status_cb=0x0,

status_cb_arg=0x0) at client.c:291

#3 0x0000000000410882 in gpgsm_agent_pksign (ctrl=0x1, keygrip=0x68bffc "",
desc=0x7fffffffd9f2 "", digest=0x68bffc "",

digestlen=20, digestalgo=2, r_buf=0x7fffffffdec8, r_buflen=0x7fffffffde18)

at ../../sm/call-agent.c:269
#4 0x00000000004179c2 in gpgsm_create_cms_signature (ctrl=0x7fffffffe0a0,
cert=0x6b2e20, md=0x69d650, mdalgo=2,

r_sigval=0x7fffffffdec8) at ../../sm/certcheck.c:430

#5 0x00000000004203e5 in gpgsm_sign (ctrl=0x7fffffffe0a0, signerlist=0x68f548,
data_fd=0, detached=1, detached@entry=0, out_fp=0x0)

at ../../sm/sign.c:707

#6 0x000000000040aa65 in main (argc=1, argv=0x7fffffffe230) at
../../sm/gpgsm.c:1798

I can easily provide more debug output.

There are a couple of ideas on how to use mail for key retrieval. We won't be
able to implement them for 2.2 but we should consider this for 2.3.

There won't be any changes for 1.4, though.

I pushed Ueno's patches for gpgme. In particular
dee56820cabde60c43c9bf8281b8d411cb2ad644

Oops; forgot to add the fix to 1.7.0

Fixed in the repo (commit 536c721)

gpg-agent does disable core dumps both in the stable and modern version.
Furthermore I have to agree with Werner here, if there is a process that can
ptrace your gpg-agent, then you have already lost anyway.

GnuPG 2.1.11 will print PROGRESS lines which allows in connection with
--exit-on-status-write-error to use that correctly. We should add that option
to gpg invocation of gpgme, though.

This was implemented for 2.1. We won't backport it to 1.4 or 2.0.

Sorry, I can't see any problem here.

The "priotr-old" key is actually the newer key because an expiration date was
added to that copy of the key (2012-07-09) and that key has meanwhile expired.
Thus you can't encrypt using this key.

When you import the "piotr" key that is actually the same key but w/o the update
with the expiration date. Thus gpg does not chnage the exiting in key because
the existing key has a newer self-signature (where the expiration date is
stored) than the new key. So nothing changes, which is correct.

If you delete the .gnupg directory you don't have the newer key and by importing
the key w/o the expiration date you can encrypt to that key.

Same behaviour with gpg-2.1.10 (Arch), libgcrypt 1.6.4.

1.4.12 is heavily outdated (from 2012). Please update to 1.4.20 or at least
1.4.19 and check again.

As I am not sure how to attach files to this report I have uploaded them here:
http://www.elstel.org/uploads/gnupg/

Err, fixed in 6ac57a48.

Fixed in

FWIW, with commit 19545e3a from 2015-09-09 I had bumped the limit up to 20MiB.
This should solve all current practical problems.

As an additional point, the client max body size in nginx defaults to 1 MiB[0].
Currently no checking is done for larger request bodies for inclusion in the
keyserver pools. Apache does not have such a limit by default.

Reference:
[0] http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

Kristian Fiskerstrand told me that the SKS keyservers currently have a 5 MB
limit for parsing incoming header, pre-merge.

It looks like this problem has been fixed in the meantime. As such, I'm marking
this bug as resolved. Thanks.

$ gpg2 --with-fingerprint 4F43C989.txt
pub rsa1024/4F43C989 2015-11-17

Key fingerprint = A8D8 E9B9 D25D 6AB8 9997  AEE4 3817 872D 4F43 C989

uid Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17
$ gpg2 --fingerprint 4F43C989
pub rsa1024/4F43C989 2015-11-17

Key fingerprint = A8D8 E9B9 D25D 6AB8 9997  AEE4 3817 872D 4F43 C989

uid [ unknown] Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17

I've fixed this with commit 0b86c74 by making it possible to select keys using
the key id. Consider:

gpg> key 4BFA08E4

pub rsa4096/D21739E9

created: 2007-06-02  expires: 2016-01-21  usage: SC  
validity: unknown

sub rsa4096/21484CFF

created: 2007-06-02  expired: 2015-02-26  usage: E

sub* rsa2048/4BFA08E4

created: 2008-06-19  expires: 2016-01-21  usage: A

sub rsa4096/1BFDFA5C

created: 2013-03-12  expires: 2016-01-21  usage: S

sub rsa2432/0CA757FB

created: 2013-09-11  expires: 2016-09-14  usage:

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub rsa4096/14D5DA70

created: 2015-01-21  expires: 2016-01-21  usage: E

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

[ unknown] (1). Daniel Kahn Gillmor <dkg@fifthhorseman.net>
[ unknown] (2) Daniel Kahn Gillmor <dkg@openflows.com>
[ revoked] (3) Daniel Kahn Gillmor <dkg@astro.columbia.edu>
[ revoked] (4) Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
[ unknown] (5) [jpeg image of size 3515]
[ unknown] (6) Daniel Kahn Gillmor <dkg@debian.org>
[ unknown] (7) Daniel Kahn Gillmor <dkg@aclu.org>

Oops. I used a plain old keyring and not a keybox. However the effect is the same.

That should go into the keylisting. Here is a listing of a revoked
key:

  pub   dsa1024/269E78D84738350A 1999-08-16 [revoked: 2011-02-15]
        Key fingerprint = 72A2 A242 8623 84A9 5910  C454 269E 78D8 4738 350A
        Keygrip = 2BBB5EF3D036022DD66EF4386680C194352A2EC2
  uid                 [ revoked] Florian Lohoff <flo@[...]>
  uid                 [ revoked] Florian Lohoff <flo@[...]>
  uid                 [ revoked] Florian Lohoff <flor[...]>

Another line after the Keygrip line could show key revocation
information. To show user id revocations a list option is anyway
required:

  $ gpg --list-options show-unusable-uids  \
     --with-fingerprint  --with-keygrip -k 6C7EE1B8621CC013
  pub   dsa1024/6C7EE1B8621CC013 1998-07-07 [expired: 2004-12-31]
        Key fingerprint = ECAF 7590 EB34 43B5 C7CF  3ACB 6C7E E1B8 621C C013
        Keygrip = E3003A38C3CCB63DFB39998A6C8A78EB9498E42A
  uid                 [ expired] Werner Koch <wk@gnupg.org>
  uid                 [ expired] Werner Koch <werner.koch@guug.de>
  uid                 [ expired] Werner Koch <wk@[...].com>
  uid                 [ revoked] Werner Koch <wk@openit.de>

A similar formatted revocation reason could be shown after the revoked
user id. It would be best to indent that to align with the [revoked]
string.

And of course we also need to come up with a --with-colon format for
both cases.

Iff we do this it should only go into 2.1 thus I changed the Version field.

My problem was a different one. Here is what I wrote to gnupg-devel:

$ ../g10/gpg2 -vsbau 0xE3FDFF218E45B72B </etc/motd >/dev/null

[...]

gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.

gpg: (check argument of option '--local-user')

gpg: error reading key block for '0xE3FDFF218E45B72B': Unknown system error.

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

gpg: Error: the key specification '1E42B367' is ambiguous.
gpg: (check argument of option '--default-key')
gpg: error reading key block for '1E42B367': Unknown system error.
gpg: writing to stdout
gpg: EDDSA/SHA256 signature from: "E3FDFF218E45B72B Werner Koch (wheatstone

commit signing)"

  wk@wheatstone:~/b/gnupg/tmp$ echo $?
  2

Note that I have only specified a short key id because this is pretty
common and gpg prints only a warning. Okay.

The real problem is that there are several error messages - one is
sufficient to let gpg exit with a failure and git won't continue. There
are 2 different kinds of errors:

  gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.

This is the keyid I specified on the command line. Let's check it:

$ ../g10/gpg2 -k 0xE3FDFF218E45B72B

[...]

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: please do a --check-trustdb
  pub   ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15]
  uid                 [ultimate] Werner Koch (wheatstone commit signing)

(and -k shows the same result).
What is the ambiguity here?

The other two error messages are identical one for --encrypt-to and one
for --default-key:

  gpg: Error: the key specification '1E42B367' is ambiguous.

Let's check it:

$ ../g10/gpg2 -k 1E42B367

[...]

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: please do a --check-trustdb
  pub   dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]
  uid                 [ unknown] Werner Koch <wk@gnupg.org>
  uid                 [ unknown] Werner Koch <wk@g10code.com>
  uid                 [ unknown] Werner Koch <werner@eifzilla.de>
  sub   dsa1024/4F0540D577F95F95 2011-11-02
  sub   rsa2048/1E0FE11D664D7444 2014-01-02 [expires: 2016-12-31]

Also not ambiguous.

So this new feature break existing installations. This is a complaint
as mentioned in T1128 (wk on Nov 06 2015, 10:57 AM / Roundup). Not due to performance but due to severe
breakage. This needs a lot more testing before we can release it.