Is Tests / Ubuntu broken at the moment?
Hello Python Developers,
I notice TLS tests failing in the ssl test suite in master, 3.9 and 3.8 branches.
https://github.com/python/cpython/runs/2018191733
Is it to do with infrastructure, certificate? I am unable to determine it exactly. The failure is observed upon merge to master. or with 3.8, 3.9 backports of any PR.
Thank you, Senthil
On Tue, Mar 2, 2021 at 6:44 PM Senthil Kumaran <senthil@python.org> wrote:
Hello Python Developers,
I notice TLS tests failing in the ssl test suite in master, 3.9 and 3.8 branches.
https://github.com/python/cpython/runs/2018191733
Is it to do with infrastructure, certificate? I am unable to determine it exactly. The failure is observed upon merge to master. or with 3.8, 3.9 backports of any PR.
It's not just you. This is holding PRs up. It started within the last ~18 hours?
-gps
For lack of better things to do with that... https://bugs.python.org/issue43382 filed to track it.
On Tue, Mar 2, 2021 at 7:30 PM Gregory P. Smith <greg@krypto.org> wrote:
On Tue, Mar 2, 2021 at 6:44 PM Senthil Kumaran <senthil@python.org> wrote:
Hello Python Developers,
I notice TLS tests failing in the ssl test suite in master, 3.9 and 3.8 branches.
https://github.com/python/cpython/runs/2018191733
Is it to do with infrastructure, certificate? I am unable to determine it exactly. The failure is observed upon merge to master. or with 3.8, 3.9 backports of any PR.
It's not just you. This is holding PRs up. It started within the last ~18 hours?
-gps
On Tue, Mar 2, 2021 at 8:29 PM Gregory P. Smith <greg@krypto.org> wrote:
For lack of better things to do with that... https://bugs.python.org/issue43382 filed to track it.
Actually, that turned out to be useful. Thank you!
The discussion with the default minimal level TLS, and way it is configured in distributions like Ubuntu, Debian, Fedora, and it's usage with Python is bit _unsettling_ from a users perspective. OpenSSL, Ubuntu, Python are heavily relied upon pieces of infrastructure. I wouldn't be surprised if more projects noticed this problem with the update to Ubuntu 20.02.
-- Senthil
On 03/03/2021 16.06, Senthil Kumaran wrote:
On Tue, Mar 2, 2021 at 8:29 PM Gregory P. Smith <greg@krypto.org> wrote:
For lack of better things to do with that... https://bugs.python.org/issue43382 filed to track it.
Actually, that turned out to be useful. Thank you!
The discussion with the default minimal level TLS, and way it is configured in distributions like Ubuntu, Debian, Fedora, and it's usage with Python is bit _unsettling_ from a users perspective. OpenSSL, Ubuntu, Python are heavily relied upon pieces of infrastructure. I wouldn't be surprised if more projects noticed this problem with the update to Ubuntu 20.02.
Hi,
for the record, the issue started when GitHub Actions updated "ubuntu-latest" was updated from 18.04 to 20.04. A user reported a similar issue on BPO last year in August and with Ubuntu last year in October. Only Ubuntu is affected. Debian, standard OpenSSL, and other distros use a different approach set minimum protocol version:
https://bugs.python.org/issue41561 https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878 https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625
PEP 644 (not approved yet) and a soon-to-be-published PEP will hopefully get rid of the problem once and for all. PEP 644 removes support for OpenSSL < 1.1 and the new PEP will remove support for TLS 1.0 and 1.1 from stdlib.
https://www.python.org/dev/peps/pep-0644/
By the way, all major distributions disable TLS 1.0 and 1.1. They also set a higher security level to block weak RSA, DH, and signatures. You can find more information about Fedora crypto policies at:
https://fedoraproject.org/wiki/Changes/CryptoPolicy https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Here are some of my fixes for crypto policies, TLS 1.0/1.1 deprecation, and FIPS:
https://bugs.python.org/issue34399 https://bugs.python.org/issue38275 https://bugs.python.org/issue38271 https://bugs.python.org/issue34542
Christian
On Wed, Mar 3, 2021 at 8:08 AM Christian Heimes <christian@python.org> wrote:
PEP 644 (not approved yet) and a soon-to-be-published PEP will hopefully get rid of the problem once and for all. PEP 644 removes support for OpenSSL < 1.1 and the new PEP will remove support for TLS 1.0 and 1.1 from stdlib.
Thank you for all the efforts here, Christian. The PEP provides a good summary on the state. +1 vote to it and hope we will have a much simpler system to reason with soon.
It was hard for me (guess anyone) to track Libre/Open/Boring, TLS versions etc, and leave alone keeping it compatible like you have been doing. The premise of PEP-0644 is extremely reasonable.
On 03/03/2021 18.59, Senthil Kumaran wrote:
On Wed, Mar 3, 2021 at 8:08 AM Christian Heimes <christian@python.org> wrote:
PEP 644 (not approved yet) and a soon-to-be-published PEP will hopefully get rid of the problem once and for all. PEP 644 removes support for OpenSSL < 1.1 and the new PEP will remove support for TLS 1.0 and 1.1 from stdlib.
Thank you for all the efforts here, Christian. The PEP provides a good summary on the state. +1 vote to it and hope we will have a much simpler system to reason with soon.
It was hard for me (guess anyone) to track Libre/Open/Boring, TLS versions etc, and leave alone keeping it compatible like you have been doing. The premise of PEP-0644 is extremely reasonable.
Thanks! :)
It's actually easy:
- BoringSSL is irrelevant unless you have a product that bundles/vendors the library as an internal dependency, e.g. Chrome.
- LibreSSL is used by OpenBSD and DragonFly.
- Everyone (*) else uses OpenSSL or moved back to OpenSSL
(*) except for Windows, macOS, Android, Java, Firefox/Thunderbird, GnuPG, embedded systems, curl, and others. curl has something like 15 different TLS backends.
On Wed, Mar 3, 2021 at 8:08 AM Christian Heimes <christian@python.org> wrote:
On 03/03/2021 16.06, Senthil Kumaran wrote:
On Tue, Mar 2, 2021 at 8:29 PM Gregory P. Smith <greg@krypto.org> wrote:
For lack of better things to do with that...
https://bugs.python.org/issue43382 filed to track it.
Actually, that turned out to be useful. Thank you!
The discussion with the default minimal level TLS, and way it is configured in distributions like Ubuntu, Debian, Fedora, and it's usage with Python is bit _unsettling_ from a users perspective. OpenSSL, Ubuntu, Python are heavily relied upon pieces of infrastructure. I wouldn't be surprised if more projects noticed this problem with the update to Ubuntu 20.02.
Hi,
for the record, the issue started when GitHub Actions updated "ubuntu-latest" was updated from 18.04 to 20.04. A user reported a similar issue on BPO last year in August and with Ubuntu last year in October. Only Ubuntu is affected. Debian, standard OpenSSL, and other distros use a different approach set minimum protocol version:
https://bugs.python.org/issue41561 https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878 https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625
PEP 644 (not approved yet)
Has this been submitted to the SC yet? I can't find an email or anything at https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644 .
-Brett
and a soon-to-be-published PEP will hopefully get rid of the problem once and for all. PEP 644 removes support for OpenSSL < 1.1 and the new PEP will remove support for TLS 1.0 and 1.1 from stdlib.
https://www.python.org/dev/peps/pep-0644/
By the way, all major distributions disable TLS 1.0 and 1.1. They also set a higher security level to block weak RSA, DH, and signatures. You can find more information about Fedora crypto policies at:
https://fedoraproject.org/wiki/Changes/CryptoPolicy https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Here are some of my fixes for crypto policies, TLS 1.0/1.1 deprecation, and FIPS:
https://bugs.python.org/issue34399 https://bugs.python.org/issue38275 https://bugs.python.org/issue38271 https://bugs.python.org/issue34542
Christian
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/J... Code of Conduct: https://www.python.org/psf/codeofconduct/
On 03/03/2021 21.54, Brett Cannon wrote:
Has this been submitted to the SC yet? I can't find an email or anything at https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644 <https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644>.
Err ... no. I was not aware that I have to formerly submit a PEP to the SC for approval. I thought that pushing the PR and announcing it on DPO was good enough.
Christian
On Wed, Mar 3, 2021 at 1:32 PM Christian Heimes <christian@python.org> wrote:
On 03/03/2021 21.54, Brett Cannon wrote:
Has this been submitted to the SC yet? I can't find an email or anything at
https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644
< https://github.com/python/steering-council/issues?q=is%3Aissue+is%3Aopen+644 .
Err ... no. I was not aware that I have to formerly submit a PEP to the SC for approval. I thought that pushing the PR and announcing it on DPO was good enough.
We ask people to explicitly tell us when they are ready for a PEP to be reviewed as we otherwise don't know when you as a PEP author think the PEP is in a finished state and is no longer changing. Otherwise we would be reading PEPs that are constantly changing underneath us as the conversation happens and PEP authors update things accordingly.
The preference is opening an issue at https://github.com/python/steering-council/issues as it's the easiest way for us to track what we are being asked to consider and for other PEP authors to know what our review queue looks like (currently sits at 5 PEPs).
participants (5)
-
Brett Cannon -
Christian Heimes -
Gregory P. Smith -
Senthil Kumaran -
Senthil Kumaran