Page MenuHome GnuPG

Timeout for receive-keys
Open, LowPublic

Description

Yesterday for some reason the keyserver pool was unresponsive. --> --recv-keys just waited indefinitely. Additional problem occurs with Enigmail, which just shows a progress bar, waiting. There is no API access to terminate gpg.exe from there, so it remains open in memory.

I think it'd be best to add a timeout-option to --recv-keys, so Enigmail will get a fitting error message in such a case and gpg.exe terminates correctly.

Details

Version
2.2.5

Event Timeline

werner edited projects, added gnupg, FAQ, Enigmail; removed Feature Request.
werner added a subscriber: werner.

man dirmngr

--connect-timeout n
--connect-quick-timeout n
       Set  the  timeout  for  HTTP  and generic TCP connection attempts to N seconds.  The
       value set with the quick variant is used when the --quick option has been  given  to
       certain Assuan commands.  The quick value is capped at the value of the regular con‐
       nect timeout.  The default values are 15 and 2 seconds.  Note that the timeout  val‐
       ues are for each connection attempt; the connection code will attempt to connect all
       addresses listed for a server.

However if the server stops or some ugly proxy sending in the middle of a transaction we have no real way to set timeout; there are just too many ways a connection can be slowed down.

Another thing is that when you import keys quite often, the trustdb (for the Web of Trust) will be rebuild every time. This is bad and thus Unix people tend to put "no-auto-check-trustdb" into their gpg.conf and add this to their crontab:

30   2 * * *   /usr/local/bin/gpg --batch --check-trustdb 2>/dev/null

AFAIK, Enigmail passes the --no-auto-check-trustdb also when importing but I don't know the details and how Enigmail makes sure that the trustdb is being rebuilt.

As far as I understand your comment there is already a timeout of 15s per connection. But as you wrote, it doesn't fit all cases. In my case, gpg.exe just stayed open indefinitely.

Is there really no way to terminate gpg.exe with an error message, if the/any command takes longer than e.g. 30s? Termination should kill open connections.

Sorry, I'm no developer, might have the wrong impression about things.

You are right in that enigmail uses no-auto-check-trustdb

In my understanding, it should be possible to wait for the gpg command pipe from a different process and then terminate the connection on a timeout, kllling the process eventually. So the Enigmail side could implement something. These days I'm not sure what Enigmail uses for OpenPGP support. Thunderbird has moved on to a different implementation and Enigmail stops supporting Thunderbird 68 in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

The recommended way to access GnuPG would be GPGME and if a timeout option would be implemented, I guess it should be implemented there. When using gpg interactively you could use send a break (e.g. Control-C on GNU-systems) to terminate the command.

@JJworx do you still have this problem, with the changes in Thunderbird? Otherwise we could close this issue?