dirmngr doesn't handle IPv6 properly

Bug #1625845 reported by Stéphane Graber on 2016-09-20
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnupg2 (Ubuntu)
Critical
Dimitri John Ledkov

Bug Description

This is a regression from gpgv1 which will prevent direct interaction with an IPv6 key server and on single and dual-stack IPv6 network, this will cause gpg to seemingly hang for up to several minutes.

=== IPv6 gpgv1 on xenial
root@xenial:~# time gpg --keyserver hkp://[2a03:4000:6:40af::1] --recv-keys 0xBAEFF88C22F6E216
gpg: requesting key 22F6E216 from hkp server [2a03:4000:6:40af::1]
gpg: key 22F6E216: "LXC pre-built images <email address hidden>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

real 0m0.341s
user 0m0.000s
sys 0m0.000s

=== IPv6 gpgv2 on xenial
root@yakkety:~# time gpg --keyserver hkp://[2a03:4000:6:40af::1] --recv-keys 0xBAEFF88C22F6E216
gpg: keyserver receive failed: Unknown host

real 0m0.827s
user 0m0.004s
sys 0m0.000s

=== Dual-stack DNS record gpgv1 on xenial
root@xenial:~# time gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 0xBAEFF88C22F6E216
gpg: requesting key 22F6E216 from hkp server pool.sks-keyservers.net
gpg: key 22F6E216: "LXC pre-built images <email address hidden>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

real 0m1.430s
user 0m0.000s
sys 0m0.000s

=== Dual-stack DNS record gpgv2 on yakkety
root@yakkety:~# time gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 0xBAEFF88C22F6E216
gpg: key BAEFF88C22F6E216: "LXC pre-built images <email address hidden>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

real 0m33.495s
user 0m0.000s
sys 0m0.004s

=== Dual-stack DNS record gpgv2 on yakkety (ipv6-only machine)
root@yakkety:~# time gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 0xBAEFF88C22F6E216
gpg: key BAEFF88C22F6E216: "LXC pre-built images <email address hidden>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

real 1m32.326s
user 0m0.004s
sys 0m0.000s

Dimitri John Ledkov (xnox) wrote :

Figuring out what dirmngr is doing in these cases, can be aided with cranking up verbosity and logging the output, e.g.:

keyserver hkp://ipv6.pool.sks-keyservers.net
log-file /tmp/tmp.pVKaTIdXs8/.gnupg/dirmngr.log
debug-level guru

Options in $GNUPGHOME/dirmngr.conf. Followed by gpgconf --kill dirmngr.

Whilst plenty of stuff is logged.... it doesn't actually tell me if he hit things over ipv6 or ipv4. It appears to be resolving a pool and picking a random thing to connect to.

Note the https://bugs.gnupg.org/gnupg/issue1989

dirmngr supposed to figure out that something is dead, is retry elsewhere. Does using hkp://ipv6.pool.sks-keyservers.net improve things for you? That pool should have all servers accessible over ipv6, unlike the main pool which may have ipv4-only servers.

Could you please crank up the logging, and check if it has excessive amount of resolving dns pools and messages marking them dead?

Dimitri John Ledkov (xnox) wrote :

Using [ipv6] address form seems to have regressed upstream. From logs, it appears that '[' ']' are dropped, and request is attempted to the 2a03 host for [2a03:4000:6:40af::1]. I shall report that upstream.

Dimitri John Ledkov (xnox) wrote :

Hm....

dirmngr[3638.0]: can't connect to 'squid.internal': no IP address for host
dirmngr[3638.0]: error connecting to 'http://ams3.sks.heypete.com:11371': Unknown host
dirmngr[3638.0]: marking host 'ams3.sks.heypete.com' as dead

Dimitri John Ledkov (xnox) wrote :

hm, however surely using ipv4/6 pools is a bandaid workaround.

Stéphane Graber (stgraber) wrote :

Yeah and not helping much if you're one of those few weird people who are on an IPv6-only network like I am :)

4dro (kwadronaut) wrote :

This was solved upstream last June:
https://dev.gnupg.org/T2990#98557
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849845

Getting 2.2.4 from bionic-proposed into bionic (and backporting for others) would be a way forward.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.