On Jan 18, 2018 07:34, "Christian Heimes" <christ...@python.org> wrote:
On 2018-01-16 21:17, Christian Heimes wrote: > FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have > created a daily cronjob to populate Travis' cache with OpenSSL builds. > Until the cache is filled, Linux CI will take an extra 5 minute. I have messed up my initial research. :( When I was checking LibreSSL and OpenSSL for features, I draw a wrong conclusion. LibreSSL is *not* OpenSSL 1.0.2 compatible. It only implements some of the required features from 1.0.2 (e.g. X509_check_hostname) but not X509_VERIFY_PARAM_set1_host. X509_VERIFY_PARAM_set1_host() is required to perform hostname verification during the TLS handshake. Without the function, I'm unable to fix Python's hostname matching code [1]. LibreSSL upstream knows about the issue since 2016 [2]. I have opened another bug report [3]. We have two options until LibreSSL has addressed the issue: 1) Make the SSL module more secure, simpler and standard conform 2) Support LibreSSL There are tons of different SSL libraries out there that we could theoretically support, but don't. IIUC, the reasons we started supporting LibreSSL in the first place were: - it claimed to be OpenSSL compatible, so supporting it is supposed to be "free" - when it started (just after heartbleed), there was a lot of uncertainty about whether OpenSSL would remain a viable option, and LibreSSL looked like it might become the new de facto standard. Now it's a few years later, and things have turned out differently: they aren't compatible in practice, and OpenSSL has turned things around so that it's clearly ahead of LibreSSL technically (cleaner API, new features like TLS 1.3, ...), and in terms of developer momentum. 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. -n
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com