Bug 794950

Both F17 and F18 builds failed due to this test case failing within test_ssl:
======================================================================
FAIL: test_openssl_version (test.test_ssl.BasicSocketTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_ssl.py", line 151, in test_openssl_version
    (s, t))
AssertionError: ('OpenSSL 1.0.1-fips-beta2 19 Jan 2012', (1, 0, 0, 0, 3))
----------------------------------------------------------------------

Both the f17 and f18 builds were against openssl-1.0.1-0.1.beta2.fc17

The last successful build of python was python-2.7.2-18.fc17:
  http://koji.fedoraproject.org/koji/buildinfo?buildID=281149
which was against openssl-1.0.0e-3.fc17

The failing assertion is (edited for conciseness):

        s = ssl.OPENSSL_VERSION
        t = ssl.OPENSSL_VERSION_INFO
        major, minor, fix, patch, status = t
        # Version string as returned by OpenSSL, the format might change
        self.assertTrue(s.startswith("OpenSSL {:d}.{:d}.{:d}".format(major, minor, fix)),
                        (s, t))

It looks like:

  ssl.OPENSSL_VERSION == 'OpenSSL 1.0.1-fips-beta2 19 Jan 2012'
  ssl.OPENSSL_VERSION_INFO == (1, 0, 0, 0, 3)

and the assertion is complaining because the string version starts with 'OpenSSL 1.0.1', whereas the tuple version is somehow 1.0.0

This probably affects the "python3" src.rpm also: the test case in Python-3.2.2 appears to share the same code.

Looking in Python-2.7.2/Modules/_ssl.c:

 ssl.OPENSSL_VERSION comes from:
    SSLeay_version(SSLEAY_VERSION)
 via this code:
  1748      r = PyString_FromString(SSLeay_version(SSLEAY_VERSION));
  1749      if (r == NULL || PyModule_AddObject(m, "OPENSSL_VERSION", r))
  1750          return;

 ssl.OPENSSL_VERSION_INFO comes from:
     SSLeay()
 via this code:
  1726      /* OpenSSL version */
  1727      /* SSLeay() gives us the version of the library linked against,
  1728         which could be different from the headers version.
  1729      */
  1730      libver = SSLeay();
  1731      r = PyLong_FromUnsignedLong(libver);
  1732      if (r == NULL)
  1733          return;
  1734      if (PyModule_AddObject(m, "OPENSSL_VERSION_NUMBER", r))
  1735          return;
  1736      status = libver & 0xF;
  1737      libver >>= 4;
  1738      patch = libver & 0xFF;
  1739      libver >>= 8;
  1740      fix = libver & 0xFF;
  1741      libver >>= 8;
  1742      minor = libver & 0xFF;
  1743      libver >>= 8;
  1744      major = libver & 0xFF;
  1745      r = Py_BuildValue("IIIII", major, minor, fix, patch, status);
  1746      if (r == NULL || PyModule_AddObject(m, "OPENSSL_VERSION_INFO", r))
  1747          return;

CCing tmraz (openssl owner)

tmraz: any thoughts?  are SSLeay() and SSLeay_version(SSLEAY_VERSION) out-of-sync somehow?

In /usr/src/debug/openssl-1.0.1-beta2/crypto/cversion.c:
    65  const char *SSLeay_version(int t)
    66          {
    67          if (t == SSLEAY_VERSION)
    68                  return OPENSSL_VERSION_TEXT;

and:
   113  unsigned long SSLeay(void)
   114          {
   115          return(SSLEAY_VERSION_NUMBER);
   116          }

/usr/include/openssl/opensslv.h has:
    28  #define OPENSSL_VERSION_NUMBER  0x10000003L
    29  #ifdef OPENSSL_FIPS
    30  #define OPENSSL_VERSION_TEXT    "OpenSSL 1.0.1-fips-beta2 19 Jan 2012"
    31  #else
    32  #define OPENSSL_VERSION_TEXT    "OpenSSL 1.0.1-beta2 19 Jan 2012"
    33  #endif

Reassigning to openssl

This is with openssl-1.0.1-0.1.beta2.fc17.x86_64

Also Ruby are FTBFS. I cannot build updated Ruby. The following tests are failing:

https://github.com/ruby/ruby/blob/trunk/test/openssl/test_x509cert.rb
https://github.com/ruby/ruby/blob/trunk/test/drb/test_drbssl.rb

(In reply to comment #7)
> Also Ruby are FTBFS. I cannot build updated Ruby. The following tests are
> failing:
> 
> https://github.com/ruby/ruby/blob/trunk/test/openssl/test_x509cert.rb
> https://github.com/ruby/ruby/blob/trunk/test/drb/test_drbssl.rb

For reference, which of these tests are failing, and how?

(In reply to comment #8)
> (In reply to comment #7)
> > Also Ruby are FTBFS. I cannot build updated Ruby. The following tests are
> > failing:
> > 
> > https://github.com/ruby/ruby/blob/trunk/test/openssl/test_x509cert.rb
> > https://github.com/ruby/ruby/blob/trunk/test/drb/test_drbssl.rb
> 
> For reference, which of these tests are failing, and how?

Actually the failures are bit different than what you described here. I opened separate issue for Ruby: https://bugzilla.redhat.com/show_bug.cgi?id=797217

Thanks.  Retitling this issue to restrict it to the thing that breaks the Python test (incoherent versioning).

Can you please drop this test from the python testsuite? Unfortunately the numeric version number has to be kept the same as was in the 1.0.0 version because it is part of the ABI. I've never seen any other application that would compare the numeric version number with the string.

I'll try to provide symbol versioning for the SSLeay() function so it returns the old version to apps compiled against 1.0.0 and a new version against apps built with 1.0.1.

Please try the build against the current rawhide - it should now return coherent version for newly built apps.

Works:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3843404

test_ssl
test_sslwrap_simple (test.test_ssl.BasicTests) ... ok
test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok
test_ciphers (test.test_ssl.BasicSocketTests) ... ok
test_constants (test.test_ssl.BasicSocketTests) ... ok
test_openssl_version (test.test_ssl.BasicSocketTests) ... ok
test_parse_cert (test.test_ssl.BasicSocketTests) ... 
{'notAfter': 'Feb 16 16:54:50 2013 GMT',
 'subject': ((('countryName', u'US'),),
             (('stateOrProvinceName', u'Delaware'),),
             (('localityName', u'Wilmington'),),
             (('organizationName', u'Python Software Foundation'),),
             (('organizationalUnitName', u'SSL'),),
             (('commonName', u'somemachine.python.org'),))}
ok

Could you do an update for f17 too please?

F17 is reverted to 1.0.0g due to other regressions.

See:
https://admin.fedoraproject.org/updates/FEDORA-2012-2665/openssl-1.0.0g-4.fc17

This fake OPENSSL_VERSION downgrade also bites Squid-3 on F16 which uses OPENSSL_VERSION to adjust to slight differences in a couple of openssl-1.0.x versions.

Unfortunately as I said there is no way to avoid that fake downgrade for released distros. On Fedora rawhide this is solved by using symbol versioning.