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.

FWIW, pth_connect is part of the regular interface.

It is okay for one request to take a long time or possibly even to block.
But it is not okay, if other, simultaniously made requests are blocked to wait
for this slow request. Especially if those parallel requests could be answered
easily and quickly, like ping.

If you ask to download a large CRL and the server is slow it takes time. If you
download a webpage with a lager image and the server is slow it takes time. The
solution is to cancel the request.

To me this, issue makes dirmngr unsuitable as a system service
and it currently allows denail of service attacks on gpgsm based email
applications.

Fwiw, the name of the new thread implementation will be npth.

If a system call blocks we are doomed to wait. We use a user land threads
implementation (Pth) and wrap most system calls so that we can handle the
blocking. However we can't do that for all system calls. We can wrap some of
them but only as long as a select can be used to wait for the system call.

Hmm thinking about this, it is almost like a denail of service attack, because
dirmngr will block other clients.

Fixed in dirmngr and also in GnuPG trunk. Patch for gpg4win created.

ping, it's important for gpg4win.

http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/dirmngr.texi?rev=334&root=Dirmngr&view=markup
@node Dirmngr Protocol
still misses LOADCRL and others as far as I can see.

Oh, lost tarck of this one.

Implemented since 1.0.2

Marcus, please apply

Right, I noticed this later.

I sent the translations as bugs #1144 (gnupg-2) and #1145 (dirmngr) a week ago.

I once fixed such a thing in the past - need to seen what goes wrong in your case.

D110: 264_dirmngr-1.0.3-allow_only_complete_dps.diff

Previous patches does not solve problem that one of DPs failes.

Just for clarification about DP list in certificate syntax and its semantics:

My previous patch does not delete all duplicate CRLs from cache if one entry is
recognised as still usable.

D111: 263_dirmngr-1.0.3-dont_overwrite_usable_crls-2.diff

D112: 262_dirmngr-1.0.3-dont_overwrite_usable_crls.diff

So, here it is. It's little verbose, be free to remove log_infos. This is output
I get (LDAP enabled) with this patch:

D114: 261_dirmngr-1.0.3-hexadecimal_serial_numbers.diff

Attached patch fixes it.

$ gpgsm --help
gpgsm (GnuPG) 2.0.11
[…]

--assume-binary              předpokládat vstup v binárním formátu

-r, --recipient ID_UŽIVATELE šifrovat pro ID_UŽIVATELE

--prefer-system-dirmngr      použít systémový dirmngr, je-li dostupný

Can you give some examples? In GnuPG we fixed that at some places.

Yes, the whole X.509 PKI busieness is a mess. However You are right that
Dirmngr should not replace a good by a broken CRL. As you can see in the code
there is a little race condition which usually has no bad effects but might come
into the game here. I have not looked at the code for weeks, though. I'd be
glad to receive a fix.

Just for completeness, there have been more fixed in dirmngr
and the symptom seems to also have happened because an http proxy
behaved
strangely.http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/crlfetch.c?root=Dirmngr&rev=323&r1=320&r2=323

I read RFC 3280 and I thing I understand it.

Sorry, I added gpgsm output without LDAP attempt because valid up-to-date CRL
for one CA was cached already. Follows output demonstrating stop on LDAP failure:

I got the idea probably. The structure of DP extension assumed by dirmngr is: