Hi, today's OpenSSL release of 1.0.2r and 1.1.1b reminded me of OpenSSL's release strategy [1]. OpenSSL 1.0.2 will reach EOL on 2019-12-31, 1.1.0 will reach EOL on 2019-09-11 (one year after release of OpenSSL 1.1.1). First the good news: There is no need to take any action for 2.7 to 3.6. As of today, Python 2.7, 3.5, and 3.6 are using OpenSSL 1.0.2. Python 3.6.8 (2018-12-24) and 3.5.5 (2018-02-05) were the last regular update with binary packages. 3.5.6 is a source-only security release. 3.6.9 will be the first source-only security release of the 3.6 series. Python 2.7 will reach EOL just a day after OpenSSL 1.0.2 reaches EOL. IMHO it's fine to ship the last 2.7 build with an OpenSSL version that was EOLed just 24h earlier. Python 3.7 and master (3.8) are affected. As of now, both branches use OpenSSL 1.1.0 and must be updated to 1.1.1 soonish. Ned has scheduled 3.7.3 release for 2019-03-25. That's still well within the release schedule for 1.1.0. I suggest that we update to 1.1.1 directly after the release of Python 3.7.3 and target 3.7.4 as first builds with TLS 1.3 support. That gives Victor, Steve, and me enough time to sort out the remaining issues. In worst case we could revert the update and postpone the update to 3.7.5. Or we disable TLS 1.3 support by default in Mac and Windows builds. Christian [1] https://www.openssl.org/policies/releasestrat.html
IMHO it's fine to ship the last 2.7 build with an OpenSSL version that was EOLed just 24h earlier.
Is this a time / cost issue or a branch policy issue? If someone was to back port the forthcoming 1.1.1 to 2.7 significantly before the EOL date, could that be merged? There are all sorts of e.g. legacy academic works that'll never be upgraded etc etc On Tuesday, February 26, 2019, Christian Heimes <christian@python.org> wrote:
Hi,
today's OpenSSL release of 1.0.2r and 1.1.1b reminded me of OpenSSL's release strategy [1]. OpenSSL 1.0.2 will reach EOL on 2019-12-31, 1.1.0 will reach EOL on 2019-09-11 (one year after release of OpenSSL 1.1.1).
First the good news: There is no need to take any action for 2.7 to 3.6. As of today, Python 2.7, 3.5, and 3.6 are using OpenSSL 1.0.2. Python 3.6.8 (2018-12-24) and 3.5.5 (2018-02-05) were the last regular update with binary packages. 3.5.6 is a source-only security release. 3.6.9 will be the first source-only security release of the 3.6 series. Python 2.7 will reach EOL just a day after OpenSSL 1.0.2 reaches EOL. IMHO it's fine to ship the last 2.7 build with an OpenSSL version that was EOLed just 24h earlier.
Python 3.7 and master (3.8) are affected. As of now, both branches use OpenSSL 1.1.0 and must be updated to 1.1.1 soonish. Ned has scheduled 3.7.3 release for 2019-03-25. That's still well within the release schedule for 1.1.0. I suggest that we update to 1.1.1 directly after the release of Python 3.7.3 and target 3.7.4 as first builds with TLS 1.3 support. That gives Victor, Steve, and me enough time to sort out the remaining issues.
In worst case we could revert the update and postpone the update to 3.7.5. Or we disable TLS 1.3 support by default in Mac and Windows builds.
Christian
[1] https://www.openssl.org/policies/releasestrat.html
_______________________________________________ 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/ wes.turner%40gmail.com
On 26/02/2019 21.31, Wes Turner wrote:
IMHO it's fine to ship the last 2.7 build with an OpenSSL version that was EOLed just 24h earlier.
Is this a time / cost issue or a branch policy issue?
If someone was to back port the forthcoming 1.1.1 to 2.7 significantly before the EOL date, could that be merged?
My mail is about official binary Python packages for Windows and macOS. We stick to an OpenSSL version to guarantee maximum backwards compatibility within a minor release. OpenSSL 1.1.1 has TLS 1.3 support and prefers TLS 1.3 over TLS 1.2. There is a small change that TLS 1.3 breaks some assumptions. Python 2.7 works mostly fine with OpenSSL 1.1.1. There are some minor test issues related to TLS 1.3 but nothing serious. Linux distros have been shipping Python 2.7 with OpenSSL 1.1.1 for a while.
There are all sorts of e.g. legacy academic works that'll never be upgraded etc etc
That topic is out of scope and has been discussed countless times.
Thanks, as always On Tue, Feb 26, 2019 at 4:45 PM Christian Heimes <christian@python.org> wrote:
On 26/02/2019 21.31, Wes Turner wrote:
IMHO it's fine to ship the last 2.7 build with an OpenSSL version that was EOLed just 24h earlier.
Is this a time / cost issue or a branch policy issue?
If someone was to back port the forthcoming 1.1.1 to 2.7 significantly before the EOL date, could that be merged?
My mail is about official binary Python packages for Windows and macOS. We stick to an OpenSSL version to guarantee maximum backwards compatibility within a minor release. OpenSSL 1.1.1 has TLS 1.3 support and prefers TLS 1.3 over TLS 1.2. There is a small change that TLS 1.3 breaks some assumptions.
Python 2.7 works mostly fine with OpenSSL 1.1.1. There are some minor test issues related to TLS 1.3 but nothing serious. Linux distros have been shipping Python 2.7 with OpenSSL 1.1.1 for a while.
There are all sorts of e.g. legacy academic works that'll never be upgraded etc etc
That topic is out of scope and has been discussed countless times.
participants (2)
-
Christian Heimes -
Wes Turner