Bug 1611810
Summary: | GnuTLS enables TLS 1.3 by default | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ben Cotton <bcotton> |
Component: | Changes Tracking | Assignee: | Nikos Mavrogiannopoulos <nmavrogi> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 29 | CC: | bitlord0xff, bugs.michael, bugzilla, nmavrogi, pasik |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-10-29 17:11:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ben Cotton
2018-08-02 19:05:28 UTC
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[1], 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 bcotton. [1] https://fedoraproject.org/wiki/Releases/29/Schedule 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. Hi, 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? Thanks 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. gnutls-3.6.3-4.fc28 gnutls-3.6.3-4.fc29 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. https://github.com/dinhviethoa/libetpan/blob/master/src/data-types/mailstream_ssl.c#L597 There's an old SNI feature request for it here: https://github.com/dinhviethoa/libetpan/issues/258 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. https://bugzilla.redhat.com/show_bug.cgi?id=1629151#c16 |