Page MenuHome GnuPG
Feed Advanced Search

Jan 23 2017

dkg set Version to 2.1.17 on T2928: stop fetching PTR records entirely.
Jan 23 2017, 10:25 PM · Debian, Bug Report, gnupg, dirmngr
dkg added projects to T2928: stop fetching PTR records entirely: dirmngr, gnupg, Bug Report, Debian.
Jan 23 2017, 10:25 PM · Debian, Bug Report, gnupg, dirmngr

Jan 19 2017

werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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.

Jan 19 2017, 12:16 PM · Debian, Bug Report, gnupg, dirmngr
werner removed a project from T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set: Restricted Project.
Jan 19 2017, 12:03 PM · Debian, Bug Report, gnupg, dirmngr
werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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

Jan 19 2017, 12:03 PM · Debian, Bug Report, gnupg, dirmngr
werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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.

Jan 19 2017, 12:00 PM · Debian, Bug Report, gnupg, dirmngr
werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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)

Jan 19 2017, 11:42 AM · Debian, Bug Report, gnupg, dirmngr
werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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

Jan 19 2017, 11:25 AM · Debian, Bug Report, gnupg, dirmngr

Jan 18 2017

dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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

Jan 18 2017, 9:24 AM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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.

Jan 18 2017, 9:21 AM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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.

Jan 18 2017, 9:03 AM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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

Jan 18 2017, 8:58 AM · Debian, Bug Report, gnupg, dirmngr

Jan 16 2017

werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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.

Jan 16 2017, 8:05 PM · Debian, Bug Report, gnupg, dirmngr

Jan 12 2017

dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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

Jan 12 2017, 5:39 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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

Jan 12 2017, 5:39 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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

Jan 12 2017, 5:38 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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.

Jan 12 2017, 5:37 PM · Debian, Bug Report, gnupg, dirmngr
werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

Can you run dirmngr with

debug dns,network
verbose

I don't think that gnutls debug is required.

Jan 12 2017, 12:32 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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:~$

Jan 12 2017, 12:37 AM · Debian, Bug Report, gnupg, dirmngr

Jan 11 2017

werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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.

Jan 11 2017, 4:48 PM · Debian, Bug Report, gnupg, dirmngr
werner added a project to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set: Restricted Project.
Jan 11 2017, 4:48 PM · Debian, Bug Report, gnupg, dirmngr
werner added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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.

Jan 11 2017, 12:51 PM · Debian, Bug Report, gnupg, dirmngr

Jan 6 2017

werner closed T1424: gpg --quiet doesn't suppress messages "requesting key XXX ..." / noise on STDERR/STDOUT as Resolved.
Jan 6 2017, 7:00 PM · gnupg, Debian, Feature Request
werner added a comment to T1424: gpg --quiet doesn't suppress messages "requesting key XXX ..." / noise on STDERR/STDOUT.

In 2.1 --quit is honored here

Jan 6 2017, 7:00 PM · gnupg, Debian, Feature Request
werner added a project to T1173: gpg has no easy way to view the reason and description of revocation sigs: gnupg (gpg22).
Jan 6 2017, 6:27 PM · gnupg, Debian, Feature Request
werner renamed T1173: gpg has no easy way to view the reason and description of revocation sigs from gnupg: has no easy way to view the reason and description of revocation sigs to gpg has no easy way to view the reason and description of revocation sigs.
Jan 6 2017, 6:27 PM · gnupg, Debian, Feature Request

Jan 5 2017

dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

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

Jan 5 2017, 10:52 PM · Debian, Bug Report, gnupg, dirmngr
dkg set External Link to https://bugs.debian.org/849845 on T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.
Jan 5 2017, 10:47 PM · Debian, Bug Report, gnupg, dirmngr
dkg added projects to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set: dirmngr, gnupg, Bug Report, Debian.
Jan 5 2017, 10:02 PM · Debian, Bug Report, gnupg, dirmngr
dkg set Version to 2.1.17 on T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.
Jan 5 2017, 10:02 PM · Debian, Bug Report, gnupg, dirmngr

Dec 16 2016

justus added a comment to T2874: sefgfault with gpgsm --sign.

Fixed in 3c7d6a1769ed6cc90d86247a814a0dce341512a3.

Dec 16 2016, 4:05 PM · gnupg, Bug Report, Debian
justus closed T2874: sefgfault with gpgsm --sign as Resolved.
Dec 16 2016, 4:05 PM · gnupg, Bug Report, Debian
aheinecke added a comment to T2874: sefgfault with gpgsm --sign.

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.

Dec 16 2016, 3:15 PM · gnupg, Bug Report, Debian

Dec 15 2016

knue added projects to T2874: sefgfault with gpgsm --sign: Debian, Bug Report.
Dec 15 2016, 3:59 PM · gnupg, Bug Report, Debian
knue set External Link to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847982 on T2874: sefgfault with gpgsm --sign.
Dec 15 2016, 3:59 PM · gnupg, Bug Report, Debian

Nov 29 2016

werner set External Link to 846175@bugs.debian.org on T2856: Can't ssh-add a key w/o a passphrase.
Nov 29 2016, 10:40 AM · Debian, Bug Report, gnupg, ssh
werner set Version to 2.1.16 on T2856: Can't ssh-add a key w/o a passphrase.
Nov 29 2016, 10:40 AM · Debian, Bug Report, gnupg, ssh
werner added projects to T2856: Can't ssh-add a key w/o a passphrase: ssh, gnupg, Bug Report, Debian.
Nov 29 2016, 10:40 AM · Debian, Bug Report, gnupg, ssh

Nov 10 2016

werner removed a project from T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call: Unreleased.
Nov 10 2016, 12:31 PM · gpgme, Bug Report, Debian

Oct 7 2016

gniibe set External Link to https://bugs.debian.org/836772 on T2739: pinentry can't access GPG_TTY after su/sudo to another user on GNU/Linux.
Oct 7 2016, 5:06 AM · Bug Report, Debian, pinentry
gniibe renamed T2739: pinentry can't access GPG_TTY after su/sudo to another user on GNU/Linux from pinentry can't access GPG_TTY after /bin/login or sudo to another user on GNU/Linux to pinentry can't access GPG_TTY after su/sudo to another user on GNU/Linux.
Oct 7 2016, 4:38 AM · Bug Report, Debian, pinentry

Oct 6 2016

gniibe renamed T2739: pinentry can't access GPG_TTY after su/sudo to another user on GNU/Linux from pinentry can't access GPG_TTY after login or sudo to pinentry can't access GPG_TTY after /bin/login or sudo to another user on GNU/Linux.
Oct 6 2016, 5:55 AM · Bug Report, Debian, pinentry
gniibe added projects to T2739: pinentry can't access GPG_TTY after su/sudo to another user on GNU/Linux: pinentry, Debian, Bug Report.
Oct 6 2016, 5:12 AM · Bug Report, Debian, pinentry

Sep 28 2016

werner removed a project from T1089: Please store requests in a cache to avoid sending out duplicate requests (mailto: interface): gnupg (gpg21).
Sep 28 2016, 9:55 AM · gnupg (gpg23), gnupg, Debian, Feature Request
werner removed Version on T1089: Please store requests in a cache to avoid sending out duplicate requests (mailto: interface).
Sep 28 2016, 9:55 AM · gnupg (gpg23), gnupg, Debian, Feature Request
werner added a project to T1089: Please store requests in a cache to avoid sending out duplicate requests (mailto: interface): gnupg (gpg23).
Sep 28 2016, 9:55 AM · gnupg (gpg23), gnupg, Debian, Feature Request
werner added a comment to T1089: Please store requests in a cache to avoid sending out duplicate requests (mailto: interface).

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.

Sep 28 2016, 9:55 AM · gnupg (gpg23), gnupg, Debian, Feature Request

Sep 22 2016

werner removed a project from T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call: In Progress.
Sep 22 2016, 9:58 AM · gpgme, Bug Report, Debian
werner closed T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call as Resolved.
Sep 22 2016, 9:58 AM · gpgme, Bug Report, Debian
werner added a project to T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call: Unreleased.
Sep 22 2016, 9:58 AM · gpgme, Bug Report, Debian
werner added a comment to T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call.

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

Sep 22 2016, 9:57 AM · gpgme, Bug Report, Debian

Sep 21 2016

werner added a comment to T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call.

Oops; forgot to add the fix to 1.7.0

Sep 21 2016, 9:46 PM · gpgme, Bug Report, Debian

Jun 8 2016

werner closed T1394: man page documents some unsupported parameters as Resolved.
Jun 8 2016, 6:06 PM · gnupg, Debian, Feature Request
werner added a comment to T1394: man page documents some unsupported parameters.

Fixed in the repo (commit 536c721)

Jun 8 2016, 6:06 PM · gnupg, Debian, Feature Request

May 17 2016

werner added projects to T2357: "minimal dunb-terminal": Not A Bug, Debian.
May 17 2016, 2:21 PM · Debian, Not A Bug, Bug Report, pinentry

May 6 2016

werner removed a project from T1060: extract signature from encrypted and signed file/message: Restricted Project.
May 6 2016, 8:28 PM · gnupg (gpg21), gnupg, Debian, Feature Request
werner closed T1060: extract signature from encrypted and signed file/message as Resolved.
May 6 2016, 8:28 PM · gnupg (gpg21), gnupg, Debian, Feature Request

Apr 5 2016

justus added a comment to T1509: gnupg2 (gpg-agent): Disable producing of core dumps for gpg-agent via prctl(PR_SET_DUMPABLE, 0) as ssh-agent does.

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.

Apr 5 2016, 2:59 PM · gnupg, Debian, gnupg (gpg20), Feature Request, gpgagent
justus closed T1509: gnupg2 (gpg-agent): Disable producing of core dumps for gpg-agent via prctl(PR_SET_DUMPABLE, 0) as ssh-agent does as Resolved.
Apr 5 2016, 2:59 PM · gnupg, Debian, gnupg (gpg20), Feature Request, gpgagent

Jan 25 2016

werner added a comment to T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call.

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.

Jan 25 2016, 11:49 AM · gpgme, Bug Report, Debian
werner added a project to T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call: In Progress.
Jan 25 2016, 11:49 AM · gpgme, Bug Report, Debian
werner reopened T1415: gpgme_cancel() does not stop gpg process from finishing asynchronous call as "Open".
Jan 25 2016, 11:49 AM · gpgme, Bug Report, Debian

Jan 15 2016

werner closed T2205: GnuPG does not detect damaged keys on import as Resolved.
Jan 15 2016, 9:57 AM · Not A Bug, Debian, Bug Report, gnupg

Jan 11 2016

werner removed Due Date on T1060: extract signature from encrypted and signed file/message.
Jan 11 2016, 3:21 PM · gnupg (gpg21), gnupg, Debian, Feature Request
werner removed a project from T1060: extract signature from encrypted and signed file/message: In Progress.
Jan 11 2016, 3:21 PM · gnupg (gpg21), gnupg, Debian, Feature Request
werner added a comment to T1060: extract signature from encrypted and signed file/message.

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

Jan 11 2016, 3:21 PM · gnupg (gpg21), gnupg, Debian, Feature Request
werner added a project to T1060: extract signature from encrypted and signed file/message: Restricted Project.
Jan 11 2016, 3:21 PM · gnupg (gpg21), gnupg, Debian, Feature Request

Jan 7 2016

werner added a project to T2205: GnuPG does not detect damaged keys on import: Not A Bug.
Jan 7 2016, 4:02 PM · Not A Bug, Debian, Bug Report, gnupg
werner removed projects from T2205: GnuPG does not detect damaged keys on import: Keyserver, gnupg (gpg14).
Jan 7 2016, 4:02 PM · Not A Bug, Debian, Bug Report, gnupg
werner added a comment to T2205: GnuPG does not detect damaged keys on import.

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.

Jan 7 2016, 4:02 PM · Not A Bug, Debian, Bug Report, gnupg

Jan 6 2016

estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

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

Jan 6 2016, 11:13 AM · Not A Bug, Debian, Bug Report, gnupg
estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Jan 6 2016, 11:13 AM · Not A Bug, Debian, Bug Report, gnupg

Jan 5 2016

werner added a comment to T2205: GnuPG does not detect damaged keys on import.

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

Jan 5 2016, 3:13 PM · Not A Bug, Debian, Bug Report, gnupg
werner lowered the priority of T2205: GnuPG does not detect damaged keys on import from Unbreak Now! to Normal.
Jan 5 2016, 3:13 PM · Not A Bug, Debian, Bug Report, gnupg

Dec 27 2015

estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Dec 27 2015, 5:51 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Dec 27 2015, 5:51 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

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

Dec 27 2015, 5:50 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb added a comment to T2205: GnuPG does not detect damaged keys on import.

Dec 27 2015, 5:50 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb added projects to T2205: GnuPG does not detect damaged keys on import: gnupg (gpg14), Keyserver, gnupg, Bug Report, Debian.
Dec 27 2015, 5:36 PM · Not A Bug, Debian, Bug Report, gnupg
estellnb set Version to 1.4.12 on T2205: GnuPG does not detect damaged keys on import.
Dec 27 2015, 5:36 PM · Not A Bug, Debian, Bug Report, gnupg

Dec 4 2015

justus closed T1038: Specify and use multiple keyservers as Resolved.
Dec 4 2015, 1:08 PM · gnupg (gpg21), gnupg, Debian, Feature Request
justus added a comment to T1038: Specify and use multiple keyservers.

Err, fixed in 6ac57a48.

Dec 4 2015, 1:08 PM · gnupg (gpg21), gnupg, Debian, Feature Request
justus added a comment to T1038: Specify and use multiple keyservers.

Fixed in

Dec 4 2015, 1:07 PM · gnupg (gpg21), gnupg, Debian, Feature Request

Dec 3 2015

justus claimed T1038: Specify and use multiple keyservers.
Dec 3 2015, 5:02 PM · gnupg (gpg21), gnupg, Debian, Feature Request

Nov 30 2015

werner added a comment to T1845: sending large keys to keyserver push fails with silent hang and "assuan_inquire failed: Too much data for IPC layer".

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

Nov 30 2015, 4:16 PM · gnupg, gnupg (gpg21), Debian, Bug Report
werner closed T1845: sending large keys to keyserver push fails with silent hang and "assuan_inquire failed: Too much data for IPC layer" as Resolved.
Nov 30 2015, 4:16 PM · gnupg, gnupg (gpg21), Debian, Bug Report

Nov 18 2015

kristianf added a comment to T1845: sending large keys to keyserver push fails with silent hang and "assuan_inquire failed: Too much data for IPC layer".

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

Nov 18 2015, 5:24 PM · gnupg, gnupg (gpg21), Debian, Bug Report
neal added a comment to T1845: sending large keys to keyserver push fails with silent hang and "assuan_inquire failed: Too much data for IPC layer".

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

Nov 18 2015, 2:23 PM · gnupg, gnupg (gpg21), Debian, Bug Report

Nov 17 2015

neal closed T1428: --fingerprint and --with-fingerprint create slightly different results as Resolved.
Nov 17 2015, 9:31 PM · gnupg (gpg21), Debian, Bug Report, gnupg
neal added a comment to T1428: --fingerprint and --with-fingerprint create slightly different results.

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

Nov 17 2015, 9:31 PM · gnupg (gpg21), Debian, Bug Report, gnupg
neal closed T1423: Description of 'key' command could be improved as Resolved.
Nov 17 2015, 9:24 PM · gnupg, Debian, Feature Request
neal added a comment to T1423: Description of 'key' command could be improved.

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>

Nov 17 2015, 9:24 PM · gnupg, Debian, Feature Request

Nov 13 2015

werner added a comment to T1128: gpg should detect ambigious keys specifications.

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

Nov 13 2015, 9:53 AM · Feature Request, Debian, gnupg

Nov 12 2015

werner changed Version from 1.4.10 to master on T1173: gpg has no easy way to view the reason and description of revocation sigs.
Nov 12 2015, 9:20 AM · gnupg, Debian, Feature Request
werner added a comment to T1173: gpg has no easy way to view the reason and description of revocation sigs.

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.

Nov 12 2015, 9:20 AM · gnupg, Debian, Feature Request
werner changed Version from 1.4.10 to master on T1128: gpg should detect ambigious keys specifications.
Nov 12 2015, 8:59 AM · Feature Request, Debian, gnupg
werner added a comment to T1128: gpg should detect ambigious keys specifications.

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.

Nov 12 2015, 8:59 AM · Feature Request, Debian, gnupg

Nov 11 2015

neal added a comment to T1128: gpg should detect ambigious keys specifications.

I've fixed the problem that Niibe reported in 7546e81.

Nov 11 2015, 11:20 PM · Feature Request, Debian, gnupg
werner reopened T1128: gpg should detect ambigious keys specifications as "Open".
Nov 11 2015, 8:38 AM · Feature Request, Debian, gnupg
werner added a comment to T1128: gpg should detect ambigious keys specifications.

(commit e8c53fc was for master)

This introduces a regression. I had to revert this commit to be able to keep on
using gpg in my configuration. A description of the problem can be found at:
https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030549.html

Nov 11 2015, 8:38 AM · Feature Request, Debian, gnupg