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.

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 was wrong about Tor and IPv6 -- Tor has had IPv6 support for years, so
something else is wrong...

This would emit the "content-encryption key", as specified in
https://tools.ietf.org/html/rfc5652#section-6.3

ah right, "ulimit -l" says 64 (kbytes) on my Linux system as well. According to
mlock(2) that's since kernel 2.6.9.

So i think it's worth adopting the supplied patch as a workaround at least (i
can confirm that it resolves the specific use case described in T2857 (dkg on Dec 05 2016, 05:47 PM / Roundup)), and i
agree with you that we should extend libgcrypt to extend secure memory allocation.

it's not clear to me that swap is outside the trust boundary anyway these days,
and modern systems should prefer encrypted swap where possible.

is the only goal of the secure memory to keep the RAM from being written to
swap, or are there other goals of secure memory? why is it unlikely that a new
block of memory can be mlock'd? what are the consequences of the new block not
being mlock'd? will it still be treated as secure memory?

crashing in the event that we run out of secure memory is simply not acceptable
these days, especially in a model where we have persistent long-term daemons
that people expect to remain running.

I just posted 0001-agent-Respect-enable-large-secmem.patch to gnupg-devel:

https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032285.html

D400: 927_0001-agent-Respect-enable-large-secmem.patch

This is a duplicate of bug 2848

fwiw, i'm seeing this too, over at https://bugs.debian.org/846953 , for a user
with an insanely large (10240-bit) RSA key when it is locked with a passphrase.

I'm attaching such an example secret key (with passphrase "abc123"), and you can
trigger the crash with:

gpg --batch --yes --import test-hugekey.key
echo test | gpg -r 861A97D02D4EE690A125DCC156CC9789743D4A89

--encrypt --armor --trust-model=always --batch --yes --output data.gpg

            gpg --decrypt data.gpg

While i think it's fair to say that we need to have some limits on the sizes of
keys we can handle, gpg-agent should not crash when asked to deal with
extra-large keys, it should fail gracefully and return a sensible error code.

I've updated the patch series here to the series we're using in debian for 2.1.16.

D389: 918_0005-dirmngr-Drop-useless-housekeeping.patch

D390: 917_0004-dirmngr-Avoid-automatically-checking-upstream-swdb.patch

D391: 916_0003-dirmngr-Lazily-launch-ldap-reaper-thread.patch

D392: 915_0002-dimrngr-Avoid-need-for-hkp-housekeeping.patch

D393: 914_0001-dirmngr-hkp-Avoid-potential-race-condition-when-some.patch

In practice, dirmngr from git master still wakes up every few seconds due to the
ldap-reaper thread, even if no connections to ldap have ever happened.

the patch dirmngr-Lazily-launch-ldap-reaper-thread.patch avoids this additional
wakeup at least for those dirmngr instances that have never used LDAP.

We're shipping these patches in debian unstable as of 2.1.15-9.

D394: 912_0145-dirmngr-Lazily-launch-ldap-reaper-thread.patch

D395: 911_0144-dirmngr-Drop-useless-housekeeping.patch

D396: 910_0143-dimrngr-Avoid-need-for-hkp-housekeeping.patch

D397: 909_0142-dirmngr-hkp-Avoid-potential-race-condition-when-some.patch

D398: 908_0141-dirmngr-More-win32-system-daemon-cleanup.patch

I submitted these patches on the gnupg-devel mailing list in November 2016:

https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032011.html

These are working for me to keep gpg-agent idle on platforms that support
inotify when the user doesn't use scdaemon, and we're now shipping with them
applied in debian unstable.

D276: 907_0140-agent-Avoid-scheduled-checks-on-socket-when-inotify-.patch

D277: 906_0139-agent-Avoid-tight-timer-tick-when-possible.patch

D278: 905_0138-agent-Allow-threads-to-interrupt-main-select-loop-wi.patch

D279: 904_0137-agent-Create-framework-of-scheduled-timers.patch

I'm also seeing this behavior when there is something wrong with the reverse DNS
lookups. For example:

Nov 08 10:54:36 alice dirmngr[1714]: handler for fd 5 started
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> # Home: /home/dkg/.gnupg
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> # Config:
/home/dkg/.gnupg/dirmngr.conf
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> OK Dirmngr 2.1.15 at your
service
Nov 08 10:54:36 alice dirmngr[1714]: connection from process 7623 (1000:1000)
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 <- GETINFO version
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> D 2.1.15
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> OK
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 <- KEYSERVER
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> S KEYSERVER
hkps://hkps.pool.sks-keyservers.net
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> OK
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 <- KS_GET --
0x2E8DD26C53F1197DDF403E6118E667F1EB8AF314
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L3: ASSERT:
mpi.c[_gnutls_x509_read_uint]:246
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L5: REC[0x7f7458003000]:
Allocating epoch #0
Nov 08 10:54:36 alice dirmngr[1714]: can't connect to 'oteiza.siccegge.de':
Invalid argument
Nov 08 10:54:36 alice dirmngr[1714]: error connecting to
'https://oteiza.siccegge.de:443': Invalid argument
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L5: REC[0x7f7458003000]: Start
of epoch cleanup
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L5: REC[0x7f7458003000]: End of
epoch cleanup
Nov 08 10:54:36 alice dirmngr[1714]: DBG: gnutls:L5: REC[0x7f7458003000]: Epoch
#0 freed
Nov 08 10:54:36 alice dirmngr[1714]: command 'KS_GET' failed: Invalid argument
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> ERR 167804976 Invalid
argument <Dirmngr>
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 <- BYE
Nov 08 10:54:36 alice dirmngr[1714]: DBG: chan_5 -> OK closing connection
Nov 08 10:54:36 alice dirmngr[1714]: handler for fd 5 terminated

This appears to be because the pool included 92.43.111.21, which has a PTR of
oteiza.siccegge.de, despite the fact that oteiza.siccegge.de has no A record.

There is no reason for dirmngr to be talking to the member of the pool by its
hostname, anyway -- it should make the connection by IP address, with the TLS
SNI set to the pool name.

D386: 903_0001-gnome3-Fall-back-to-curses-if-screensaver-is-locked.patch

Attached is a patch to check for locked screensaver and fall back to curses if
detected.

Perhaps gcr needs to refuse to prompt in the event that the graphical session is
known-idle/locked (in screensaver mode, whatever). Then the pinentry could know
to fall back to the tty because of the locked screen.

I just spent a while trying to research this, and i'm afraid that the code i've
written to detect whether gcr is available does nothing to detect whether the
screen is currently locked.

Furthermore, when "getpin" is called against a dbus session that is locked, it
immediately returns with a "Cancelled" message, in a way that is pretty
difficult to diagnose.

However, it looks like i can query the gnome screensaver via dbus to see whether
the screen is locked. From the command line, that's:

dbus-send --print-reply=literal --session --dest=org.gnome.ScreenSaver

/org/gnome/ScreenSaver org.gnome.ScreenSaver.GetActive

which returns a boolean true or false depending on whether the screen is locked.

We'd just need to translate it into GDBus, i think, perhaps using something
higher-level like g_dbus_connection_call(), or something lower-level, like
g_dbus_connection_send_message_with_reply() (or their synchronous variants):

file:///usr/share/doc/libglib2.0-doc/gio/GDBusConnection.html#g-dbus-connection-call
file:///usr/share/doc/libglib2.0-doc/gio/GDBusConnection.html#g-dbus-connection-send-message-with-reply

In your example, i don't think updatestartuptty is necessary for text-mode
prompting -- the "gpg --decrypt …" process will be able to detect which tty it
is connected to and pass it to the agent.

But the question here has to do with graphical consoles as well, and i don't
think there's a clear answer yet.

There are two X11 graphical sessions in the example:

a) the local machine's graphical console, where the user is currently sitting,
running ssh *to* the remote machine
b) the remote machine's graphical console, where the user is logged in, but idle

There are also three kinds of pinentry user-attention-getting mechanisms:

0) terminal

1. X11
2. d-bus

finally, i'll note that there are (at least) two d-bus user sessions running in
this example: on the remote host and on the local host. I'm assuming in this
example that the user has a single shared d-bus session across all logins on the
computer (this is the dbus-user-session model, which is well-aligned with the
gpg-agent standard-socket model, where there is one running process per user per
machine)

Since "ssh -X remote" forwards the X11 session but not the d-bus session, any
d-bus-based pinentry (like pinentry-gnome3) will connect to the d-bus session on
the remote machine. But the d-bus session on the remote machine is *also*
connected to the remote graphical (X11) console.

pinentry on the remote machine has two choices:

x) talk to the d-bus session it is connected to (which will trigger a prompt on
the remote graphical console, or
y) fall back to curses

If it chooses (x) then the user is unlikely to see the prompt (they're not
sitting in front of that graphical console). But it's not clear how to
distinguish the situation from normal use in order to choose (y).

Perhaps gcr needs to refuse to prompt in the event that the graphical session is
known-idle/locked (in screensaver mode, whatever). Then the pinentry could know
to fall back to the tty because of the locked screen. If it does that, then the
error case (where the graphical prompt is shown on the idle session) is limited
to situations where the user left the remote graphical console unlocked. I
don't know whether we can get gcr to report that successfully or not, though.

How many people has this happened to? how many people haven't known to find you
on freenode and ask about it? how many people have just given up on gpg
instead, or just decided "2.1 is broken"?

Shouldn't we fix this for them?

I like this work, thanks for it! I wonder whether it would also be useful for
full-match userID, not only for a raw e-mail address?

For example, if i query for '=Peter Palfrader' or '=ssh://host.example', it
ought to give me the key with the highest-validity binding for the requested
user ID.

(see on-list discussion at
https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056978.html)

I'm trying to understand this, but I'm not seeing it.

Here's the test i did. While recording all traffic from my machine on port 53
(the dns port), i ran:

    GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr

That interactive session looked like this:

> getinfo dnsinfo
OK - ADNS w/o Tor support
> getinfo tor
dirmngr[11713.1]: command 'GETINFO' failed: False
ERR 167772416 False <Dirmngr> - Tor mode is NOT enabled
> keyserver --clear
OK
> keyserver hkps://hkps.pool.sks-keyservers.net
OK
> keyserver --resolve hkps://hkps.pool.sks-keyservers.net
dirmngr[11713.1]: DNS query returned an error or no records: No such domain

(nxdomain)

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'bone.digitalis.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'ip-209-135-211-141.ragingwire.net'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'gpg.nebrwesleyan.edu'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'host-37-191-220-247.lynet.no'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'cryptonomicon.mit.edu'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'zimmerman.mayfirst.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'sks.srv.dumain.com'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'b4ckbone.de'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'sks.spodhuis.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'oteiza.siccegge.de'

    S # https://cryptonomicon.mit.edu:443
    OK
    > keyserver --hosttable
    S # hosttable (idx, ipv6, ipv4, dead, name, time):
    S #   0       hkps.pool.sks-keyservers.net
    S #   .   --> 8 1 5* 3 4 2 10 9 7 6
    S #   1   4   bone.digitalis.org v4=212.12.48.27
    S #   2   4   ip-209-135-211-141.ragingwire.net v4=209.135.211.141
    S #   3   4   gpg.nebrwesleyan.edu v4=192.94.109.73
    S #   4   4   host-37-191-220-247.lynet.no v4=37.191.220.247
    S #   5   4   cryptonomicon.mit.edu v4=18.9.60.141
    S #   6   4   zimmerman.mayfirst.org v4=216.66.15.2
    S #   7   4   sks.srv.dumain.com v4=85.119.82.209
    S #   8   4   b4ckbone.de v4=193.164.133.100
    S #   9   4   sks.spodhuis.org v4=94.142.242.225
    S #  10   4   oteiza.siccegge.de v4=92.43.111.21
    OK
    >

So, the SRV lookup did indeed fail, but subsequent queries succeeded.

I've attached a pcapng file of the network traffic sent and received from the
described test.

The textual version of the traffic is:

query 0x311f SRV _hkp._tcp.hkps.pool.sks-keyservers.net
query response 0x311f No such name SRV

_hkp._tcp.hkps.pool.sks-keyservers.net SOA ns2.kfwebs.net

query 0x3120 A hkps.pool.sks-keyservers.net
query response 0x3120 A hkps.pool.sks-keyservers.net A 92.43.111.21 A

94.142.242.225 A 193.164.133.100 A 85.119.82.209 A 216.66.15.2 A 18.9.60.141 A
37.191.220.247 A 192.94.109.73 A 209.135.211.141 A 212.12.48.27

query 0xbd61 PTR 27.48.12.212.in-addr.arpa
query response 0xbd61 PTR 27.48.12.212.in-addr.arpa PTR bone.digitalis.org
query 0x384a PTR 141.211.135.209.in-addr.arpa
query response 0x384a PTR 141.211.135.209.in-addr.arpa PTR

ip-209-135-211-141.ragingwire.net

query 0xb36e PTR 73.109.94.192.in-addr.arpa
query response 0xb36e PTR 73.109.94.192.in-addr.arpa PTR gpg.nebrwesleyan.edu
query 0xcac3 PTR 247.220.191.37.in-addr.arpa
query response 0xcac3 PTR 247.220.191.37.in-addr.arpa PTR

host-37-191-220-247.lynet.no

query 0xd28b PTR 141.60.9.18.in-addr.arpa
query response 0xd28b PTR 141.60.9.18.in-addr.arpa PTR cryptonomicon.mit.edu
query 0x4be9 PTR 2.15.66.216.in-addr.arpa
query response 0x4be9 PTR 2.15.66.216.in-addr.arpa CNAME

2.0-27.15.66.216.in-addr.arpa PTR zimmerman.mayfirst.org PTR zimmermann.mayfirst.org

query 0x823b PTR 209.82.119.85.in-addr.arpa
query response 0x823b PTR 209.82.119.85.in-addr.arpa PTR sks.srv.dumain.com
query 0x3b0c PTR 100.133.164.193.in-addr.arpa
query response 0x3b0c PTR 100.133.164.193.in-addr.arpa PTR b4ckbone.de
query 0x9600 PTR 225.242.142.94.in-addr.arpa
query response 0x9600 PTR 225.242.142.94.in-addr.arpa PTR sks.spodhuis.org
query 0xed36 PTR 21.111.43.92.in-addr.arpa
query response 0xed36 PTR 21.111.43.92.in-addr.arpa PTR oteiza.siccegge.de

thanks, that seems to have resolved the problem in my tests.

I'm attaching the lsof and strace transcript in text form so it can be read
without linebreaks

This is apparently just re-reported on gnupg-users:

https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056892.html

So i don't think it's fixed.

And fwiw, it seems like a clear bug to me if i use "ssh-add" and then it is not
added to the agent.

From the ssh-add's client's perspective, some keys are magically never added,
but others are. This kind of mystery behavior is confusing and frustrating. If
gpg-agent is going to handle the ssh-agent protocol, it should aim toward behave
as the user of the ssh-agent protocol expects, regardless of whether the user
knows that they're using gpg-agent or some other implementation.

another item for consistency is gpg-agent's different behavior between
--enable-ssh-socket and --extra-socket (and the undocumented --browser-socket,
for that matter, but since it's not documented maybe it's fine to just change
that one).

Agreed, but i ran into this while looking at python-gnupg, which is now failing
when using GnuPG 2.1. so they're facing breakage either way. It would be
better to have all current releases doing the expected behavior than to imagine
that we can bump this variance in behavior along indefinitely.