...for PGP keyservers.

This is quite obvious in the code:

  err = http_open (&http,
                   post_cb? HTTP_REQ_POST : HTTP_REQ_GET,
                   request,
                   httphost,
                   /* fixme: AUTH */ NULL,
                   httpflags,
                   /* fixme: proxy*/ NULL,
                   session,
                   NULL,
                   /*FIXME curl->srvtag*/NULL);

thanks for opening this bug.

The original reporter was on 2.1.0.

It looks like I can confirm this on 2.1.3.

I can confirm that this is resolved in 2.1.3:

0 dkg@alice:~$ gpgconf --launch dirmngr
gpgconf: error running '/usr/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/bin/gpg-connect-agent --dirmngr NOP': General error
1 dkg@alice:~$

the error message isn't particularly helpful at directing the user to the source
of the problem (a bad dirmngr.conf), but at least it does return a non-zero
error code.

I would like to see this happen. It would be great if dirmngr could make
parcimonie obsolete, for example.

(should this be "category: dirmngr" instead of just adding it as a topic?)

This was fixed by:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=6619ead2cfd2abcb95b66dc70622fdeef624fb8a

using the test described in T1921 (aheinecke on Mar 10 2015, 06:13 PM / Roundup) there are no longer duplicated certificates
shown after the verify command.

Thanks!

I can't reproduce this problem neither in our company setup nor on a vanilla debian.

I've placed the .der files in the correct directories
/var/lib/dirmngr/extra-certs and /etc/dirmngr/trusted-certs

gpgsm --import aheinecke.der

Dirmngr output shows that the LOOKUP Issuer and Intermediate -Cert are not not
found in the dirmngr cache and they are not imported into the keyring.

This is probably another bug that hid this issue in the past.

This was a change in behavior in 2.1 (relative to 2.0 / 1.4) in which instead of
taking the last specified key server, all key servers were used. I've now
reverted this in f26ba14028d34845ae10aae552b90681907e377d.

Changing component to gnupg with topic dirmngr in the hope to get more
visibility and because dirmngr is part of the gnupg repo in 2.1

Thanks. Fixed with commit dc10d46.

Patch and commentary uploaded to T1792, where it really belongs.

The attached patch fixes hkps: hostname verification and makes
hkps: use SNI correctly.

The patch is against GnuPG 2.1.2. It has been tested successfully against
hkps://hkps.pool.sks-keyservers.net on FreeBSD 10.1 using GnuTLS 3.2.21 and the
2.1 setup instructions at https://sks-keyservers.net/overview-of-pools.php#pool_hkps

D275: 586_poolname_and_SNI.patch

Except the for doubled listing, is there any other potential drawback?

Compiling with latest npth instead of latest pth does not change anything.
Without patch = segfault, with patch = works.

D283: 555_0001-dirmngr-Clean-up-spawned-dirmngr_ldap-processes.patch

This problem is due to ldap_wrapper creating processes with gnupg_spawn_process
but while gnupg_spawn_process states that you have to call gnupg_wait_process
and gnupg_release_process afterwards this is not done in the ldap_wrapper.

Sometimes release is called but never wait to get the exit status of the spawned
process and remove the zombie.

If release is not called this will also leak a handle on Windows.

Attached Patch moves the process cleanup in it's own function and calls that
function from where the process should be terminated and cleaned up.

My test for this:
export GNUPGHOME=$(mktemp -d)
echo "11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70 S" >
$GNUPGHOME/trustlist.txt
gpgsm --verify signed-smime-test.asc

Applied as 091c35e. Thanks.

D280: 540_gpg211-dirmngr.patch

Sorry, this is not a bug. If you configure with out TLS support it simply can't
do that. In case you are talking about the Windows installer, please note that
this binary version is marked as experimental with several limitations

Well, that is quite possible. I have seen other reports about this. I have not
yet come around to look at the hkps bugs.

original; report was for the dirmngr package. Won't fix it there.

dirmngr is now part of gnupg proper.
Original report was for dirmngr-1.1.0.

The sem_post in enter_pth can't set ERRNO because we assert the return value
later. However, the sem_wait in leave_npth has the usual EINTR protection and
thus changes ERRNO. Needs to be fixed.

Okay, fixed with commit 5cb6df8.

No this was on "the master of the day"

And with the dead server detection the case for "localhost lookup" already got
better.

But you could look at npth src/npth.c
I am pretty sure that npth_enter and npth_leave modify errno and that this
causes at least npth_connect not to set errno as expected.

This was straight 2.1.0, right? Please try again with 2.1.1 there are just to
many bugs fixs that it is not worth to look at 2.1.0. If it is still the case I
can look at (although that you assigned yourself ;-)

I had another go at this bug this evening. I had a keyserver with reproducable
failures (while I still could use it in gpg1). And suddenly during debugging it
all changed and worked flawlessly. I was down to npth_connect and after I had
added debug output in there it began to work (and kept working after removing
the debug output again, hrmpf)

With regards to the test case from T1773 (aheinecke on Nov 26 2014, 10:35 PM / Roundup). This now (after e8c0ed7 ) returns a
dead host.

Btw. I think the error message could be improved for dead hosts.

gpg2 --keyserver hkp://127.0.0.1 --search foobar
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

Should be something like "No reachable keyserver found"

Assigned this bug to me to at least provide a clearer example.

Thanks for fixing the 127.0.0.1 lookup error :)

As noted on the ML we do our own selection from the pool and consider only A and
AAAA records. This needs to be changed of course. Unfortunately this won't go
into 2.1.1.

The problem was with that specific keyserver. If I use another keyserver it
works. The keyserver was the first one returned to me by using the
keys.gnupg.net pool and as gpg 1 works with it.

I've debugged the issue.

The test case is now reduced to:
gpg2 --keyserver hkp://127.0.0.1 --search foobar

Dirmngr logs:

2014-11-26 20:35:55 dirmngr[5892.1] getnameinfo returned for '127.0.0.1':
'localhost'
2014-11-26 20:35:55 dirmngr[5892.1] can't connect to '127.0.0.1': Success
2014-11-26 20:35:55 dirmngr[5892.1] error connecting to
'http://127.0.0.1:11371': System error w/o errno
2014-11-26 20:35:55 dirmngr[5892.1] command 'KS_SEARCH' failed: System error w/o
errno

In my case this is because common/http.c (connect_server) ~ line 2200

  ai->ai_family == AF_INET && (flags & HTTP_FLAG_IGNORE_IPv4)

Returns true for 127.0.0.1 (same for 75.75.183.132 which also explains why it
works with gnupg) the address is skipped but it is the only one -> loop finishes
with no errno set.

It is set in dirmngr/ks-engine-hkp.c which looks to me like: "If it is not
indicated that a host either uses IPv4 nor IPv6 ignore it." Which i find kind of
harsh. At least a debug output like:

      if (!hi->v4 && !hi->v6)
        log_debug("Ignoring host\n");

Should be added there and of course connect_server should return an appropiate
error in case it never actually tried to connect to a server.

While debugging this I think I found another issue. You are using errno after
my_connect calls. If this expands to npth_connect the actual calls are

enter_npth()
sem_post() modifies errno
connect() modifies errno
leave_npth()
sem_wait() //modifies errno

Afaik enter / leave in npth should save errno. I could not confirm that this is
really an issue with a test but I think it is.

That is really not a bug but a design decision.

The keyserver interface in dirmngr is quite modular and the idea is to add new
interfaces as need arises. Simlar to the smartcard support in scdaemon.

Given that there is no more need for copyright assignments, adding patches shold
not be major problem. So, yes pacthes are accepted - please do it for now as a
complete separate ks-engine-hkpms.c. If we later see that it shares much code
with *-hpk we can merge it then. This better isolates bugs.

With dirmngr 1.1.1 and libgcrypt-1.6.0 (gpg4win-2.2.2-beta19) I have what I
think is a similar error on Windows:

C:\Users\aheinecke>"c:\Program Files\GNU\GnuPG\dirmngr.exe"
dirmngr[3060]: Fatal: can't register GNU Pth with Libgcrypt: Not supported

Doesn't crash though. I've not tested the pth_init patch. If you think this is
useful please tell me and I will do so. I assume it will also fix this problem.

Thanks.

Changing category to dismngr to remind about doing a release.

To also fix Issue1449, enhance my correction this way:

  rc = ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, LDAP_VERSION3);
  if (rc)
    {
      log_error (_("setting LDAPv3 for `%s:%d' failed: %s\n"),
                 host, port, ldap_err2string (rc));
      /* FIXME: Need deinit (ld)?  */
      return -1;
    }
  rc = ldap_simple_bind_s (ld, opt.user, opt.pass);
  if (rc)
    {
      log_error (_("binding to `%s:%d' failed: %s\n"),
                 host, port, ldap_err2string (rc));
      /* FIXME: Need deinit (ld)?  */
      return -1;
    }

And add translations for the new error message.

Thank you

This is an old one, but we may want to get a new dirmngr release out anyway.