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.

Because we decided that 5 minutes are reasonable value timeout value for an
intermittently slow CRL server. I can't see the actually problem with it: The
proxy should not delay or buffer the request at all. CRLs are picked up
automagically an you don't have control over what CRL server is used - if there
is a slow one and the timeout is too short you will never ever be able to use a
certificate bound to that CRL server. Better to wait than to be sorry - these
are the usual tradeoffs you have to make while defining a timeout. Note
thatthere are a couple of other timeouts in a TCP network, which you can't
control either.

What is the reason that the "last resort timeout" cannot be configured
to be faster? (Meaning below 5 minutes?)

Well you can configure it: That last resort timeout is 5 minutes plus the
configured timeout.

The first version of dirmngr that worked on any Windows reasonably well is
1.0.2. Versions before that had a multitude of issues, so I am closing this
report. If there are particular problems with current dirmngrs on 64 bit Vista,
please report them with the appropriate level of details.

The current svn trunk features a user provided trust anchors. Thus if a CRL
could not be validated just because the trust anchor is not available in
trusted-certs/, dirmnngr will casche the CRL anyway and ask back whether the
user trusts the trust anchor. The latest GnuPG implements the counterparts
which uses the /.gnupg/trustlist.txt to answer this.

I can't see a bug here. By design CRLs are only loaded once in a while and
valid as long as specified in the CRL. There is no need to re-check the CRL.
If you do not want such a behaviour you need to use OCSP and not CRLs. In fact
that is one of the reasons why the German Qualified Signatures require the use
of OCSP.

Hi Werner,