Fix TLS timeouts with recent versions of GnuTLS #330
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
gnutls_handshake_set_timeout
takes a timeout value in ms, but we were providing a value in seconds.This means that on new-enough platforms that use GnuTLS (e.g., Debian Buster), we would accidentally configure a timeout 1,000 times shorter than requested.
In particular, I was seeing this when trying to use Delta Chat (https://github.com/deltachat/deltachat-core) in Debian. Compiled on Stretch, I could connect fine. Compiled on Buster, the connection always failed:
Compiled on Stretch, the connection always succeeded. Delta sets a timeout of 10 seconds on its connections; 10ms is not long enough to negotiate SSL, but perhaps the mailimap default (30 seconds -> 30ms) is?
I tried running delta against a libetpan with this one-line patch, and it solved the problem for me.
This is preventing delta from getting into pureos for the librem5 linux mobile device: https://source.puri.sm/Librem5/chatty/issues/96