#155 Reintroduce the OPENSSL_CONF=/non-existing-file workaround
Merged 4 years ago by churchyard. Opened 4 years ago by churchyard.
rpms/ churchyard/python3 openssl_config_workaround  into  master

file modified
+9
@@ -1031,6 +1031,15 @@ 

    ConfName=$1

    ConfDir=$(pwd)/build/$ConfName

  

+   # Fedora sets explicit minimum/maximum TLS versions.

+   # Python's test suite assumes that the minimum/maximum version is set to

+   # a magic marker. We workaround the test problem by setting:

+   export OPENSSL_CONF=/non-existing-file

+   # https://bugzilla.redhat.com/show_bug.cgi?id=1618753

+   # https://bugzilla.redhat.com/show_bug.cgi?id=1778357

+   # https://bugs.python.org/issue35045

+   # https://bugs.python.org/issue38815

+ 

    echo STARTING: CHECKING OF PYTHON FOR CONFIGURATION: $ConfName

  

    # Note that we're running the tests using the version of the code in the

Since crypto-policies-20191002-1.gitc93dc99.fc32, the maximum version of TLS
is customized in Fedora as well.

See https://bugzilla.redhat.com/show_bug.cgi?id=1778357

This reverts commit b33b4a5.

IMHO test_ssl is too strict: Debian and Fedora buildbot workers had to use OPENSSL_CONF=/non-existing-file workaround, but now FreeBSD has a similar issue: https://bugs.python.org/issue38815

@vstinner I agree. We even attempted to do that in https://github.com/python/cpython/pull/11508 but it was rejected by @cheimes

Correction, my proposal was in https://github.com/python/cpython/pull/11508#issuecomment-453186969 and it was not rejected by @cheimes, but was determined too complicated by you.

rebased onto 4b316fd

4 years ago

Added the links.

The test was amended in 3.9, 3.8 and 3.7. Rather than backporting the commit, I would still go with this workaround. It's easier. We just need to keep the bugzilla open and eventually remove this again when Python is updated.

Agreed?

cc @torsava

As long as we keep the bug open and go over it on triages, it sounds good to me.

Pull-Request has been merged by churchyard

4 years ago