Page MenuHome GnuPG
Create Task
Maniphest T1313

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

Description

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 

DE122F58CE35FEBBEEBB3D0D87D690605C20D8EE

dirmngr[20405.0]: checking distribution points

dirmngr[20405.0]: fetching CRL from 

`http://corporate-pki1.telekom.de/cdp/Deutsche%20Telekom%20Root%20CA%202.crl'



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("195.243.179.225")}, 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.
Details
Version 
2.1.0beta1 
Related Objects
Event Timeline
bernhard added a subscriber: bernhard.Jan 18 2011, 4:24 PM
324_DTAG_Issuing_CA_i01.der1 KBDownload
bernhard added projects: dirmngr, Bug Report.Jan 18 2011, 4:24 PM
bernhard set Version to 2.1.0beta1.
bernhard added a subscriber: • werner.
bernhard added a comment.Jan 18 2011, 4:27 PM
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
• werner added a subscriber: marcus.Jan 19 2011, 9:07 AM
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

Windows.
• werner added a project: npth.Jan 19 2011, 9:08 AM
Fwiw, the name of the new thread implementation will be npth.
bernhard added a comment.Jan 19 2011, 9:37 AM
To me this, issue makes dirmngr unsuitable as a system service

and it currently allows denail of service attacks on gpgsm based email

applications.
• werner added a comment.Jan 19 2011, 4:51 PM
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.
bernhard added a comment.Jan 19 2011, 5:42 PM
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.
marcus added a comment.Jan 19 2011, 6:48 PM
FWIW, pth_connect is part of the regular interface.
• werner added a comment.Jan 19 2011, 7:38 PM
Hmmm, I'll do a test tomorrow.
• werner added a comment.Jan 20 2011, 3:27 PM
Fixed in commit 62842cc for gnupg master (2.1)
• werner removed a project: npth.Jan 20 2011, 3:27 PM
• werner added a project: Restricted Project.Jan 20 2011, 3:32 PM
• werner added a comment.Jan 20 2011, 3:38 PM
Also fixed in the old dirmngr, svn 347
• werner closed this task as Resolved.May 10 2011, 10:30 AM
• werner removed a project: Restricted Project.
No response, assuming the test was positive.
bernhard reopened this task as Open.May 10 2011, 4:37 PM
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.
bernhard added a project: Restricted Project.May 11 2011, 11:37 AM
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?
• werner added a comment.May 18 2011, 3:34 PM
Oh well, the svn syncing stopped quite some time ago.  Just renabled it and 347

should no be on cvs.gnupg.org
bernhard added a comment.May 19 2011, 2:37 PM
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 closed this task as Resolved.May 19 2011, 4:02 PM
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 .