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:

I did some debugging and I found that problem is not that it does not give up on
first successfully fetched CRL regardless expiration time. The real problem is
it simply fetches from all DPs and it rewrites the CRL with CRL from next DP on
each iteration.

Refocussing this issue on the "hang" symptom.

I guess I found it. The process was simply leaking file descriptors during the
LOOKUP commands. This should explain the hangings we noticed by some folks.
The fix is in svn rev 318. It boils down to this little patch:

I have an strace log for the time before the kill, it is quite boring only
4130804 lines of
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)

New log with svn rev 313 send to Werner on friday. The user had killed dirmngr.
(I am putting the internal reference in the topic.)

Can someone please check this?

I changed some diagnostics to better track possible problems. You may want to
try svn rev 313.

Is it possible to write out a message when we hit such a timeout?
Make that timeout configurable nontheless?

Werner, thanks for the quick response.
Yes I know that OPTION is generic, the question is what OPTIONs are supported
for a server and this is not mentioned for dirmngr and there is also no mention
of "audit-events" at all. Maybe audit-events is also generic?

OPTION is a generic Asssuan command and as such not Dirmngr specific.
Listed two times becuase it is two times in the table. I removed the second one
from libassuan. To go into the next libassuan release.

Okay, systematically, sending HELP to dirmngr 1.0.2 gives me the following
list:'# NOP\n# CANCEL\n# OPTION\n# BYE\n# AUTH\n# RESET\n# END\n# HELP\n#
OPTION\n# LDAPSERVER\n# ISVALID\n# CHECKCRL\n# CHECKOCSP\n# LOOKUP\n#
LOADCRL\n# LISTCRLS\n# CACHECERT\n# VALIDATE\n# INPUT\n# OUTPUT\nOK\n'

Hmmm the "LDAPSERVER" command is also not mentioned.