Ah nevermind. I think myself that this is nobug and current behavior is correct.
There is a mechanism for the redundant setup that we want to have already and we
need to use it instead of doing something undefined.

D364: 829_0001-Dirmngr-Treat-multiple-crlDPs-as-redundancies.patch

Ah, the world of S/MIME related RFCs,.. Fun.

From RFC 5280 4.2.1.13. CRL Distribution Points:
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.

So the short Answer is. Intevation's certificate is bad. If we want to mark that
our Certificate Revocation lists are Redundant then we should have used a list
in the crlDP and not multiple crlDPs. This GnuPG would handle correctly.

Before I noticed beforementioned bit I've tried to fix it in GnuPG. And I think
it might be an improval as the same section also says:

If the DistributionPoint omits the reasons field, the CRL MUST
include revocation information for all reasons. This profile
RECOMMENDS against segmenting CRLs by reason code. When a conforming
CA includes a cRLDistributionPoints extension in a certificate, it
MUST include at least one DistributionPoint that points to a CRL that
covers the certificate for all reasons.

So If we have one such list we don't have to fetch all crlDP's and error out if
one can't be obtained.

I've attached a patch for that but I can fully understand If you don't think
this should be applied as the current behavior is mature and conforms to the RFC
already. In that case you can resolve this as "nobug".

Fixed in 9354293.

That is for LDAP keyservers.

D344: 787_fix-2235.patch

I believe your problem is fixed in 9f0ba508. With that change I was able to
build gnupg-2.1.11 using speedo in a very minimal Debian jessie chroot.

To test this change, please apply the attached patch (generated using 'git diff
gnupg-2.1.11 dirmngr/Makefile.am' from gnupg master).

If the problem persists, feel free to reopen this bug.

That particular problem is fixed in 9a1778ab. Can you be more specific on the
other problem(s)?

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?