Page MenuHome GnuPG

dirmngr: Timeouts are too long
Closed, ResolvedPublic

Description

If you connect dirmngr to an unresponsive host it takes too long to fail.

This is a problem:
a) For CRL checks
b) For WKS, where mail servers might not offer a HTTPS connection and just drop
received packages on the HTTPS port. (Don't have an example MSP that does that
so this is a minor bug imo)
c) For Keyserver access

These three cases cause problems in the User Experience:

a: When we verify a Mail verification takes too long. So a Gui may need special
code to show the unverified contents before verification. In Outlook I currently
don't do that. KMail does.

b: On account setup we need to decide weather or not to offer WKS publishing.
The supported call needs to return in an acceptable time for this or we would
have to do some time of timeout in the UI.

c: Creates the same problem as a but for OpenPGP if auto-key-retrieve is used
and the keyserver is unresponsive.

Testcase for b:
time /opt/gnupg/libexec/gpg-wks-client --supported foo@1.1.1.1
gpg-wks-client: checking support failed: Connection timed out
/opt/gnupg/libexec/gpg-wks-client --supported foo@1.1.1.1 0.00s user 0.00s
system 0% cpu 2:07.22 total

Testcase for c:
echo foo | gpg2 -sa > /tmp/msg
GNUPGHOME=$(mktemp -d) gpg2 --keyserver 1.1.1.1 --auto-key-retrieve --verify
/tmp/msg
time GNUPGHOME=$(mktemp -d) gpg2 --keyserver 1.1.1.1 --auto-key-retrieve
--verify GNUPGHOME=$(mktemp -d)
gpg: keybox '/tmp/tmp.vNY8lUwtX0/pubring.kbx' created
gpg: Signature made Tue 08 Nov 2016 10:38:41 AM CET
gpg: using RSA key 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1
gpg: requesting key 1FDF723CF462B6B1 from hkp server 1.1.1.1
gpg: requesting key 1FDF723CF462B6B1 from hkp server 1.1.1.1
gpg: Can't check signature: No public key

gpg2 --keyserver 1.1.1.1 --auto-key-retrieve --verify 0.00s user 0.00s system
0% cpu 16:58.90 total

Testcase for case a would be to create a certificate with an unresponsive ca server.

I think a timeout of ~10 seconds would be appropriate.

Details

Version
master

Event Timeline

The TCP specs demand something different and it is not the duty of dirmngr to do
something about it. You have ths behavour with all TCP connections and that is
also what makes TCP a reliable connection.

On Linux if would be possible to reduce the intial SYN retries but that is not
portable.

For --auto-key-retrieve I already implemented a --quick parameter in gpg to
advise dirmngr to give up earlier. The dirmngr side has not been implemented,
though.

werner claimed this task.

Lot's of things changed in the meantime.