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.

I merged in the translation to the gnupg package, where dirmngr now resides.

Dirmngr 2.1.0-gitde7cfc0 also stays active.

Testing the fix:

Oh well, the svn syncing stopped quite some time ago. Just renabled it and 347
should no be on cvs.gnupg.org

The repository contains outdated translations. Before releasing gnupg-2.0.17, I
had been poked by Werner and I have sent updated translation of gnupg2 back.
It's part of 2.0.17 release. You must have stored current translation somewhere
else.

I merged it into gnupg where dirmngr now resides. The cs.po file there is
probably out of date anyway though and may need some massaging.

Werner, where is the patch for dirmngr 1.1.0?
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/?root=Dirmngr only goes up to rev346,
while you say rev347 has the fix. Maybe a missing sync on the svn repositories
on your part?

Haven't had a chance to test it, I was somehow waiting for a new release.
Just made sure I get a 1.1.0 patched package to test next.

No response, assuming the test was positive.

Thanks. I solved it slighly different by skipping the cache check completely.
Fix is in gnupg 1.5 because dirmngr is now a part of gnupt, proper.

Also fixed in the old dirmngr, svn 347

Fixed in commit 62842cc for gnupg master (2.1)

Hmmm, I'll do a test tomorrow.