Page MenuHome GnuPG

dirmngr unresponsive when waiting for some http CRL connect() -> ping and other requests fail
Closed, ResolvedPublic


dirmngr (GnuPG) 2.1.0beta1 and older versions like 1.1.0 stop being responsive
when waiting for a connect some http CRLs. This makes dirmngr unusable as a
system service as other request could be served just fine, but are not.

How I could reproduce it. I am using dirmngr 2.1.0beta and start it locally:

Pasting the resulting DIRMNGR_INFO value into two shells.
dirmngr-client --ping now works. Asking for verify the attached certificate.

dirmngr-client DTAG_Issuing_CA_i01.der

Results in
dirmngr[20405.0]: handler for fd 0 started
dirmngr[20405.0]: connection from process 20406 (1001:1001)
dirmngr[20405.0]: no CRL available for issuer id
dirmngr[20405.0]: checking distribution points
dirmngr[20405.0]: fetching CRL from

On the other shell
dirmngr-client --ping
now waits.

strace -p 20405

Process 20405 attached - interrupt to quit
connect(1, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("")}, 16

also waits.
I guess there will be a certain firewall behaviour trying to access this http
address, I got this send with an email and it happened that my client
trying to just verify the email just froze. Later it even froze for other
operations, probably still having that request somewhere.
My expecation is that just the text is shown in the client, even when
verification waits for something.



Event Timeline

bernhard set Version to 2.1.0beta1.
bernhard added a subscriber: werner.

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

bernhard raised the priority of this task from Normal to High.Jan 18 2011, 4:27 PM

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.

Marcus and me developed a plan to replace Pth by a new implementation which
allows to wrap any system call. We use this kind of implementaion already under

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

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

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.

CRLs are the problem. What shall we do? If the server sends only one byte a
second it will take ages and if all mails require the same CRL they all need to
wait for it. Nothing we can do about it except for implementing an upper limit
on how long it may take to download a CRL. 10 Seconds, 10 Minutes, an hour - it
depends on your connection and the server.

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.

FWIW, pth_connect is part of the regular interface.

Fixed in commit 62842cc for gnupg master (2.1)

Also fixed in the old dirmngr, svn 347

werner removed a project: Restricted Project.

No response, assuming the test was positive.

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.

Werner, where is the patch for dirmngr 1.1.0? only goes up to rev346,
while you say rev347 has the fix. Maybe a missing sync on the svn repositories
on your part?

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

Testing the fix:

Package: dirmngr Version: 1.1.0-0kk2
hang still occurs.

Now trying with Version: 1.1.0+r347-0kk1
The ping on the other shell works now.

-> Fix seems to work for the "old" dirmngr.

bernhard removed a project: Restricted Project.

Dirmngr 2.1.0-gitde7cfc0 also stays active.

Using dirmngr 1.1.0+r347-0kk1 with kontact e35 also unfreezes contact
in the event of trying to verify a signature on an email signed with a
certificate from DTAG_Issuing_CA_i01.der .