This is a tracking bug for Change: GnuTLS enables TLS 1.3 by default
For more details, see: https://fedoraproject.org/wiki/Changes/GnuTLS-TLS1.3
This change enables TLS 1.3 (draft28) support on the gnutls crypto library.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.
According to the Fedora 29 schedule, today is the deadline for changes to be in a testable state. If your change is ready to be tested, please set the status to ON_QA. A list of incomplete changes will be sent to FESCo tomorrow for evaluation. If you know your change will not be ready for Fedora 29, you can set the version to rawhide and notify email@example.com.
If I point Firefox at https://tls13.crypto.mozilla.org/ then I get a failure. If I point wget to the same URL I get an index.html which contains "You've reached a demo server that's running TLS 1.3 (draft 28) using NSS."
Is this a reasonable test and are the results expected?
Yes that's a reasonable test. Note that we should provide a new update of gnutls to use the final tls1.3 version instead of the draft 28.
Sorry for spamming this tracker bug. Is anyone who understands this able to take a look at bug #1629151 claws-mail started behaving strangely, displaying invalid2.invalid certificates like in bug #1611815 . Is it possible that it's a bug in claws-mail triggered by this change?
As a side-note here, comparing gnutls package EVR between F28 and F29 was the first I had done, since the culprit had to be outside Claws Mail.
Unfortunately, the %changelog does not mention the switch to TLS 1.3 and doesn't mention the conditional build changes either.
It would have been helpful, if the %changelog had been more accurate about the difference between F28, F29 and later.
If it cannot be avoided within gnutls, libetpan is the second package that would need to be developed further, since being the backend lib that Claws Mail uses.
There's an old SNI feature request for it here:
That server seems to have different behavior when operating under TLS1.3 in comparison with TLS1.2. TLS1.3 enablement was the trigger for this issue, but didn't cause it.