Message 335047 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	gregory.p.smith
Recipients	christian.heimes, gregory.p.smith, pablogsal
Date	2019-02-07.23:30:29
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1549582230.01.0.874575191145.issue35925@roundup.psfhosted.org>
In-reply-to

Content
I had emailed Christian around the same time you filed this. """ The problem likely not related to your hardware. I guess it's caused by tightened crypto polices. OpenSSL 1.1.1 has disabled some weak crypto. Some platforms like Debian and RHEL require even larger key sizes or have disable some algorithms. Does the test also fail with the env var OPENSSL_CONF set to a non-existing path? """ - christian.heimes testing that theory... setting OPENSSL_CONF=/invalid-path does indeed "fix" (work around) the failures. Presumably by relaxing the default system constraints. I could have that env var set for this buildbot and eliminate the failure. But do we _want_ to do that? Anyone who compiles CPython and tries to run the test suite on a modern system with such an OpenSSL configuration is going to see similar failures and likely come to us first asking about them. It seems like we'd be better off adjusting our test suite to work around the constraints or disable them only for the duration of a test intentionally violating them?

I had emailed Christian around the same time you filed this.

"""
The problem likely not related to your hardware. I guess it's caused by
tightened crypto polices. OpenSSL 1.1.1 has disabled some weak crypto.
Some platforms like Debian and RHEL require even larger key sizes or
have disable some algorithms. Does the test also fail with the env var
OPENSSL_CONF set to a non-existing path?
""" - christian.heimes

testing that theory... setting OPENSSL_CONF=/invalid-path does indeed "fix" (work around) the failures.  Presumably by relaxing the default system constraints.

I could have that env var set for this buildbot and eliminate the failure.  But do we _want_ to do that?  Anyone who compiles CPython and tries to run the test suite on a modern system with such an OpenSSL configuration is going to see similar failures and likely come to us first asking about them.

It seems like we'd be better off adjusting our test suite to work around the constraints or disable them only for the duration of a test intentionally violating them?

History
Date	User	Action	Args
2019-02-07 23:30:32	gregory.p.smith	set	recipients: + gregory.p.smith, christian.heimes, pablogsal
2019-02-07 23:30:30	gregory.p.smith	set	messageid: <1549582230.01.0.874575191145.issue35925@roundup.psfhosted.org>
2019-02-07 23:30:29	gregory.p.smith	link	issue35925 messages
2019-02-07 23:30:29	gregory.p.smith	create