| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bug 2594
|
|
While this was a bug using GnuTLS, the test is rather generic
and the expected behaviour does not depend on the TLS implementation.
|
|
Fixed in bd95ffc2ba87fbd3c752df17bc8fd9c01586d45a
|
|
|
|
deliveries as default
|
|
|
|
|
|
pri-string, disable TLS1.3
On GnuTLS 3.6.5 is appears to ignore the given priority, if it can use 1.3
|
|
|
|
|
|
We have lost one log line, for a ciphers-negotiation failure on an early
host in a list from routing. We still get something indicative if the
last one fails, so I'm going to let this pass.
Test 2025 will fail on earlier GnuTLS library versions as a result.
NONE no longer works as documented, in priority string for GnuTLS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
transport dispatch level when the transport does hosts-override. Instead do the
full trasport process call and let it decide on compatibility with the connection.
|
|
|
|
|
|
for 2x38
|
|
I've not found an equivalent in OpenSSL of gnutls_record_cork() nor gnutls_record_check_pending() yet.
|
|
|
|
|
|
open both for
further recipients and for eventual delivery.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
