Hide Forgot
Description of problem: RPM build of python within a Mock chroot fails on test_protocol_sslv2 and test_options unit tests in the %check section. Version-Release number of selected component (if applicable): python-2.7.5-34.el7 How reproducible: Building Python for EL7 inside of Mock or Koji. Steps to Reproduce: 1. yumdownloader --source python 2. sudo mock -r epel-7-x86_64 --rebuild python-2.7.5-34.el7.src.rpm You can also just "EXTRATESTOPTS='--verbose test_ssl' make test". Actual results: test_version_basic (test.test_ssl.ThreadedTests) ... test test_ssl failed -- multiple errors occurred ok ====================================================================== ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests) Connecting to an SSLv2 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-2.7.5/Lib/test/test_ssl.py", line 2155, in test_protocol_sslv2 try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv23, True) File "/builddir/build/BUILD/Python-2.7.5/Lib/test/test_ssl.py", line 1936, in try_protocol_combo chatty=False, connectionchatty=False) File "/builddir/build/BUILD/Python-2.7.5/Lib/test/test_ssl.py", line 1866, in server_params_test s.connect((HOST, server.port)) File "/builddir/build/BUILD/Python-2.7.5/Lib/ssl.py", line 846, in connect self._real_connect(addr, False) File "/builddir/build/BUILD/Python-2.7.5/Lib/ssl.py", line 837, in _real_connect self.do_handshake() File "/builddir/build/BUILD/Python-2.7.5/Lib/ssl.py", line 810, in do_handshake self._sslobj.do_handshake() error: [Errno 104] Connection reset by peer ====================================================================== FAIL: test_options (test.test_ssl.ContextTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-2.7.5/Lib/test/test_ssl.py", line 142, in f return func(*args, **kwargs) File "/builddir/build/BUILD/Python-2.7.5/Lib/test/test_ssl.py", line 694, in test_options self.assertEqual(ssl.OP_ALL, ctx.options) AssertionError: 2147484663 != 2164261879L Expected results: est_protocol_sslv2 (test.test_ssl.ThreadedTests) Connecting to an SSLv2 server with various client options ... PROTOCOL_SSLv2->PROTOCOL_SSLv2 CERT_NONE PROTOCOL_SSLv2->PROTOCOL_SSLv2 CERT_OPTIONAL PROTOCOL_SSLv2->PROTOCOL_SSLv2 CERT_REQUIRED {PROTOCOL_SSLv23->PROTOCOL_SSLv2} CERT_NONE {PROTOCOL_SSLv3->PROTOCOL_SSLv2} CERT_NONE {PROTOCOL_TLSv1->PROTOCOL_SSLv2} CERT_NONE {PROTOCOL_SSLv23->PROTOCOL_SSLv2} CERT_NONE {PROTOCOL_SSLv23->PROTOCOL_SSLv2} CERT_NONE {PROTOCOL_SSLv23->PROTOCOL_SSLv2} CERT_NONE ok AND test_options (test.test_ssl.ContextTests) ... ok Additional info: I attempted to build using Mock on EL7 and on Koji that ran on EL6, though the target was also EL7 on Koji.
Hello. Due to a recent update of openssl, SSLv2 connections were disabled, so Python's upstream test suite will cause failure of the build. You can either disable all tests in the SPEC file by modifying the line "%global run_selftest_suite 1" to "%global run_selftest_suite 0" or if you are comfortable with creating patches, you can create one that disables these specific tests and apply it through the SPEC file. You would need to make changes in the source code for Lib/test/test_ssl.py line 694: self.assertEqual(ssl.OP_ALL, ctx.options) to self.assertEqual(ssl.OP_ALL | ssl.OP_NO_SSLv2, ctx.options) lines 2155, 2163, 2165: Change the True's to False for try_protocol_combo function in these lines. We are aware of this issue and will be addressed for the next release. Any more info you would need? Should I close this bug?
Hi Charalampos, A colleague mentioned seeing the upstream bug relating to this after I filed this ticket. I've been taking the patching approach, and builds so far work great. Thanks for taking the time to explain the situation in a concise manner! Closing is fine. Is the work for the next release being tracked somewhere I can follow?
(In reply to Shatil Rafiullah from comment #4) > Hi Charalampos, > > A colleague mentioned seeing the upstream bug relating to this after I filed > this ticket. > > I've been taking the patching approach, and builds so far work great. Thanks > for taking the time to explain the situation in a concise manner! Closing is > fine. Is the work for the next release being tracked somewhere I can follow? Glad to hear that it is now working for you. I am not aware if there is something where you can track the progress, however you could utilize the bugzilla search for python or the components that you are interested in and public bugs should be visible (and maybe the progress for some). If you have any more issues do not hesitate to contact me. Regards.