Re-assigning to GnuPG. It won't be fixed in the old dirmngr package.

Fixed with commit 12c665b for gnupg 2.1.11.
The patch is different to not break the translations.

Thanks. I did some modifications and also fixed an unrelated bug in the
detection of the poolname. Will go into 2.1.11.

I'm attaching an updated patch that doesn't just ship sks-keyservers.netCA.pem
in the distributed tarball, but installs it during "make install" in pkgdatadir,
and then checks during query time to see if it should be used.

In particular, if the user asks for "hkps://hkps.pool.sks-keyservers.net" and
they haven't specified any hkp-cacert argument in dirmngr, it automatically
tries to load the bundled cert.

D340: 736_0001-Use-sks-keyservers-CA-by-default-for-the-hkps-pool.patch

Related issue: #1166.

I'm not sure, I reverted said change, and it still works for me:

% echo -e "KEYSERVER hkp://ipv6.pool.sks-keyservers.net/\nKS_SEARCH CADE3658\n"

dirmngr[10105.0]: marking host '[2a01:4f8:192:f5::3]' as dead
dirmngr[10105.0]: marking host '[2001:41d0:2:a8b4::10]' as dead
dirmngr[10105.0]: marking host '[2001:67c:2050:1000::3:4]' as dead
dirmngr[10105.0]: marking host 'hufu.ki.iif.hu' as dead

Changed to

  provided.  These are the same as the @option{--keyserver-options} of
  @command{gpg}, but apply only to this particular keyserver.

Thanks. Should actually be explained here but we wait for this until keyserver
features have been removed from gpg.

[I granted you full user rights].

May this be related to you fix for

if(ai->family != AF_INET6)

commit 23ea641b ?

Werner, in https://lists.gnupg.org/pipermail/gnupg-users/2015-May/053617.html you wrote:

The real bug is that dirmngr does not mark the v6 address dead and
retry anotyer server (or the v4 address).

I cannot reproduce this. I pointed dirnmngr to ipv6.pool.sks-keyservers.net and servers
got marked as dead as expected.

Fixed in c9f5aa15.

Fixed in a9e0b1dd.

Fixed in eb54fca.

Fixed in 1e3dbb15.

This has since been corrected. Thanks.

(At least) 2.1.9 should support version 3 (see dirmngr/ks-engine-ldap.c:492).
If this is still not working, please reopen this bug. Thanks.

A workaround is to use

GNUPGHOME=<something> gpg2 ...

so that Dirmngr also seen GNUPGHOME. I'll look into this bug. Thanks for
reporting.

This is a really old patch. Since it was reported, dirmngr has been
significantly reworked and integrated into GnuPG. Further, GnuPG's configure.ac
checks for ber_free. Since this is (I'm assuming) in the same SO as ber_alloc
(which this patch checks for) this patch is already effectively applied. Given
this, I'm closing this issue.

Werner: This patch is still relevant and it only changes diagnostics so it
shouldn't impact any existing code. Okay to apply?

Fixed with commit fa15a71 for 2.1.10. Thanks.

re T2120 (wk on Oct 19 2015, 07:54 PM / Roundup): of course I meant "Now".

Thanks for the quick fix!

No available with 2.1.9.

Done with commit 9db6547. Thanks for reminding me about this annoyance.

No problem!

Regarding ipv6. It's not that my OS doesn't support it, it's that the network I
am currently connected to (on my laptop) is not providing IPv6. There's nothing
to say that I won't move to another network that does.

Detecting IPv6 capability would be useful, but (I think) difficult. Especially
since I can move between networks in the lifetime of a single dirmngr. If I move
from a network *without* IPv6 to a network *with* IPv6, should dirmngr realise
and re-enable IPv6?

Anyway, we should open a new bug for this?

P.S.

The fix is applied to OpenBSD ports 2.1.8.

Cheers

Thanks for debugging the problem. I have pushed the fix which will go into 2.1.9.

(I neglected to implement an autogrow of reftbl and instead decided to set an
upper limit and shrink the table at the end.)

The common way to solve the v6 problems would be to add an --v4-only and
-v6-only option to dirmngr. However, it would be better to detect a non-working
v6 connectivity and disable v6.

Haven't seen this problem for months and npth-1.2 contains the fix.

-> Resolved.

The unusable hosts is a separate issue. I don't have IPv6 connectivity. I can
work around this by using the ipv4 sks pool.

OK, I think the crash is a use-after free, caused by a realloc followed by a use
of the old dangling pointer.

The following patch fixes this. Can someone on the GPG team review and commit
this for me? I can deal with fixing this in the OpenBSD ports tree. Thanks.

• dirmngr/ks-engine-hkp.c.orig Tue Sep 29 15:05:02 2015

+++ dirmngr/ks-engine-hkp.c Tue Sep 29 15:05:26 2015
@@ -512,7 +512,7 @@ map_host (ctrl_t ctrl, const char *name, int force_res

  xfree (reftbl);
  return err;
}

• qsort (reftbl, refidx, sizeof *reftbl, sort_hostpool);

+ qsort (hi->pool, refidx, sizeof *reftbl, sort_hostpool);

  }
else
  xfree (reftbl);

FWIW, after setting MALLOC_FLAGS="s", I get:

dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'openpgp.us'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'jupiter.zaledia.com'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'schluesselbruecke.de'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'keys-
02.licoho.de'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'host-
550b4a17.sileman.net.pl'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'keyserver.mattrude.com'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'dreamcoat.che.uct.ac.za'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'194.94.127.122'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'RESISP-
209-135-211-141.smf.ragingwire.net'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'pkqs.net'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'openpgp-
keyserver.de'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:4d88:1ffc:477::7]'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:67c:2050:1000::3:4]'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2a01:a500:385:1::9:1]'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'mira.cbaines.net'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:bc8:3d90:103::]'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:470:b2a7:1:225:90ff:fe93:e9fc]'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:1488:ac15:fffe::4]'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2a00:b9c0:e::4]'
dirmngr[16846.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2604:a880:800:10::688:e001]'
dirmngr[16846.0]: can't connect to '2001:470:b2a7:1:225:90ff:fe93:e9fc': No 
route to host
dirmngr[16846.0]: error connecting to 
'http://[2001:470:b2a7:1:225:90ff:fe93:e9fc]:11371': No route to host
dirmngr[16846.0]: command 'KS_SEARCH' failed: No route to host
ERR 167804970 No route to host <Dirmngr>

I ran again and got:

KEYSERVER --clear hkp://pool.sks-keyservers.net
KS_SEARCH blah@sometesst.ext
OK
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'RESISP-
209-135-211-141.smf.ragingwire.net'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'dreamcoat.che.uct.ac.za'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'pkqs.net'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'host-
550b4a17.sileman.net.pl'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'keys-
02.licoho.de'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'jupiter.zaledia.com'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'194.94.127.122'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'schluesselbruecke.de'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'openpgp.us'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'keyserver.mattrude.com'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2604:a880:800:10::688:e001]'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2a00:b9c0:e::4]'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:470:b2a7:1:225:90ff:fe93:e9fc]'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 'openpgp-
keyserver.de'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:4d88:1ffc:477::7]'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'mira.cbaines.net'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:1488:ac15:fffe::4]'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:67c:2050:1000::3:4]'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2a01:a500:385:1::9:1]'
dirmngr[16131.0]: getnameinfo returned for 'pool.sks-keyservers.net': 
'[2001:bc8:3d90:103::]'
dirmngr[16131.0]: error accessing 'http://194.94.127.122:11371/pks/lookup?
op=index&options=mr&search=blah%40sometesst%2Eext': http status 404
dirmngr[16131.0]: command 'KS_SEARCH' failed: No data
ERR 167772218 No data <Dirmngr>

Seems like it doesn't crash with malloc flags on (which is weird). I'm not sure
how dirmngr is supposed to work, but from what i gather the SKS pool has loads
of broken hosts. I've not gotten a working one yet. Surely this can't be right?

No. I won't maintain all that stuff again.

Yes I thought to use GnuTLS here.

The depedencies I see [1] are:
gmp -> No further depedencies
libgnurx -> No further dependencies
nettle -> depenendcy to gmp

Apart from that gettext and zlip which we already have.
So it should not be that hard to package. I really would like to get rid of it,
too but until then..

Would you accept a patch against gnupg to include GnuTLS 3.x in the Windows
installer?

1: https://github.com/mxe/mxe/blob/master/src/gnutls.mk

yes there are no remaining problems that I can see here.

Thanks -> resolved.

aheinecke: Did you had a chance to test this with 2.1.7 or master?

We can't use gnutls because it depends on too many extra libraries duplicating
functionality we already have in gnupg. ntbtls will be the way forward.
Unfortunately too many other tasks delayed its development.

yeah no, With the gnupg-w32 installer becoming part of gpgwin we really need
support for hkps in that installer. Yeah gnutls sucks but thats what we have.

I'll prepare a patch.