<div dir="ltr"><div class="gmail_default" style="font-size:small">On Fri, Jan 19, 2018 at 12:09 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div><div class="gmail_extra"><div class="gmail_quote">On Jan 18, 2018 07:34, "Christian Heimes" <<a href="mailto:christian@python.org" target="_blank">christian@python.org</a>> wrote:<br type="attribution"><blockquote class="m_-2853322797199993769m_4378182386436317394quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-01-16 21:17, Christian Heimes wrote:<br>
> FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have<br>
> created a daily cronjob to populate Travis' cache with OpenSSL builds.<br>
> Until the cache is filled, Linux CI will take an extra 5 minute.<br>
<br>
I have messed up my initial research. :( When I was checking LibreSSL<br>
and OpenSSL for features, I draw a wrong conclusion. LibreSSL is *not*<br>
OpenSSL 1.0.2 compatible. It only implements some of the required<br>
features from 1.0.2 (e.g. X509_check_hostname) but not<br>
X509_VERIFY_PARAM_set1_host.<br>
<br>
X509_VERIFY_PARAM_set1_host() is required to perform hostname<br>
verification during the TLS handshake. Without the function, I'm unable<br>
to fix Python's hostname matching code [1]. LibreSSL upstream knows<br>
about the issue since 2016 [2]. I have opened another bug report [3].<br>
<br>
We have two options until LibreSSL has addressed the issue:<br>
<br>
1) Make the SSL module more secure, simpler and standard conform<br>
2) Support LibreSSL<br></blockquote></div></div></div><div dir="auto"><br></div></span><div dir="auto"><div class="gmail_default" style="font-size:small;display:inline">​[...]</div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><span style="font-family:sans-serif">We have *very* few people qualified to maintain the ssl module, so given the new landscape I think we should focus on keeping our core OpenSSL support solid and not worry about LibreSSL. If LibreSSL wants to be supported as well then – like any other 2nd tier platform – they need to find someone to do the work. And if people are worried about supporting more diversity in SSL implementations, then PEP 543 is probably the thing to focus on.</span></div><span class="HOEnZb"><font color="#888888"><div dir="auto"><br></div></font></span></div></blockquote><div><div class="gmail_default" style="font-size:small;display:inline">​Given the hard limit on resources it seems only sensible to focus on the "industry standard" library​. I'm rather disappointed that LibreSSL isn't a choice, but given the lack of compatibility that's hardly Python's problem.</div></div><div>
<br></div></div><br></div></div>