Bug 1462211 - symbol SSL_CTX_set_srp_username, version OPENSSL_1_1_0 not defined in file libssl.so.1.1 with link time reference
symbol SSL_CTX_set_srp_username, version OPENSSL_1_1_0 not defined in file li...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: openssl (Show other bugs)
rawhide
All All
unspecified Severity urgent
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-16 08:31 EDT by Lukas Slebodnik
Modified: 2017-06-16 13:09 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-16 11:07:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lukas Slebodnik 2017-06-16 08:31:01 EDT
Description of problem:
New functions were added into existing version script without bumping version. Which is against philosophy of version script because it should help linker to distinguish between version compatible changes between releases.

As a result of this rpm cannot reliably add dependency on new release because SONAME is the same  and required versions in version script are the same as well. But there is new dependency on function SSL_CTX_set_srp_username.

This is a huge problem for libcurl which was build against latest version of openssl but rpm could not automatically detect new dependency on the latest version of openssl. Therefore still requires older version of openssl with missing functions. As a result of this neither dnf nor yum-deprecated nor rpm works due to missing symbols

Version-Release number of selected component (if applicable):
openssl-libs-1.1.0f-3.fc27.x86_64

How reproducible:
Deterministic

Steps to Reproduce:
1. objdump -T /lib64/libssl.so.1.1 | grep OPENSSL_1_1_0 | wc -l
2. objdump -p /lib64/libssl.so.1.1 | grep -A6 "Version definitions:"

Actual results:
  [root@vm-124 tmp]# rpm -q openssl-libs
  openssl-libs-1.1.0f-3.fc27.x86_64
  [root@vm-124 tmp]# objdump -T /lib64/libssl.so.1.1 | grep OPENSSL_1_1_0 | wc -l
  832
  [root@vm-124 tmp]# objdump -T /lib64/libssl.so.1.1 | grep   SSL_CTX_set_srp_username
  000000000004ff40 g    DF .text  0000000000000018  OPENSSL_1_1_0 SSL_CTX_set_srp_username
  000000000004ffe0 g    DF .text  0000000000000016  OPENSSL_1_1_0 SSL_CTX_set_srp_username_callback
  [root@vm-124 tmp]# objdump -p /lib64/libssl.so.1.1 | grep -A6 "Version definitions:"
  Version definitions:
  1 0x01 0x0779bbb1 libssl.so.1.1
  2 0x00 0x066d1f10 OPENSSL_1_1_0
  3 0x00 0x06d1f104 OPENSSL_1_1_0d
          OPENSSL_1_1_0 

  Version References:


Expected results:
// there should be also "OPENSSL_1_1_0f" or something similar because 42 new functions were added between versions    
openssl-libs-1.1.0e-1.fc27.x86_64 and openssl-libs-1.1.0f-3.fc27.x86_64

Additional info:

  [root@vm-124 tmp]# rpm -q openssl-libs
  openssl-libs-1.1.0f-3.fc27.x86_64
  [root@vm-124 tmp]# objdump -T /lib64/libssl.so.1.1 | grep OPENSSL_1_1_0 | wc -l
  832

  [root@b1affa9d7f3a /]# rpm -q openssl-libs
  openssl-libs-1.1.0e-1.fc27.x86_64
  [root@b1affa9d7f3a /]# objdump -T /lib64/libssl.so.1.1 | grep OPENSSL_1_1_0 | wc -l
  790
  [root@b1affa9d7f3a /]# objdump -p /lib64/libssl.so.1.1 | grep -A6 "Version definitions:"
  Version definitions:
  1 0x01 0x0779bbb1 libssl.so.1.1
  2 0x00 0x066d1f10 OPENSSL_1_1_0
  3 0x00 0x06d1f104 OPENSSL_1_1_0d
          OPENSSL_1_1_0 

  Version References:
Comment 1 Lukas Slebodnik 2017-06-16 08:35:08 EDT
And here is an example how it broke all package managers in rawhide

[root@vm-153 fedora_rawhide]# docker run -ti --rm fedora:rawhide bash
[root@239b7f7e5d0e /]# dnf install -y --setopt=debuglevel=0 --setopt=errorlevel=0 microdnf yum
[root@239b7f7e5d0e /]# 
[root@239b7f7e5d0e /]# rpm -q libcurl openssl-libs
libcurl-7.54.1-1.fc27.x86_64
openssl-libs-1.1.0e-1.fc27.x86_64
[root@239b7f7e5d0e /]# 
[root@239b7f7e5d0e /]# dnf update -y openssl-libs
Python detected LC_CTYPE=C: LC_CTYPE & LANG coerced to C.UTF-8 (set another locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behavior).
Traceback (most recent call last):
  File "/usr/bin/dnf", line 57, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.6/site-packages/dnf/__init__.py", line 31, in <module>
    import dnf.base
  File "/usr/lib/python3.6/site-packages/dnf/base.py", line 26, in <module>
    from dnf.comps import CompsQuery
  File "/usr/lib/python3.6/site-packages/dnf/comps.py", line 29, in <module>
    import dnf.util
  File "/usr/lib/python3.6/site-packages/dnf/util.py", line 32, in <module>
    import librepo
  File "/usr/lib64/python3.6/site-packages/librepo/__init__.py", line 1077, in <module>
    import librepo._librepo
ImportError: /lib64/libcurl.so.4: symbol SSL_CTX_set_srp_username, version OPENSSL_1_1_0 not defined in file libssl.so.1.1 with link time reference
[root@239b7f7e5d0e /]# 
[root@239b7f7e5d0e /]# yum-deprecated update -y openssl-libs
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.

There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   /lib64/libcurl.so.4: symbol SSL_CTX_set_srp_username, version OPENSSL_1_1_0 not defined in file libssl.so.1.1 with link time reference

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7.13 (default, Jun  1 2017, 09:53:47) 
[GCC 7.1.1 20170526 (Red Hat 7.1.1-2)]

If you cannot solve this problem yourself, please go to 
the yum faq at:
  http://yum.baseurl.org/wiki/Faq
  

[root@239b7f7e5d0e /]# microdnf update -y openssl-libs
microdnf: relocation error: /lib64/libcurl.so.4: symbol SSL_CTX_set_srp_username, version OPENSSL_1_1_0 not defined in file libssl.so.1.1 with link time reference
Comment 2 Tomas Mraz 2017-06-16 09:29:50 EDT
I am sorry, but I do not want to diverge from upstream on the symbol versions.
Comment 3 Lukas Slebodnik 2017-06-16 10:57:03 EDT
(In reply to Tomas Mraz from comment #2)
> I am sorry, but I do not want to diverge from upstream on the symbol
> versions.

Then it need to be fixed in upstream as well. New symbols should not be added to the version which was already released.
Comment 4 Tomas Mraz 2017-06-16 11:03:04 EDT
This was not the case this time - I've just enabled SRP support because it was now allowed by legal.
Comment 5 Tomas Mraz 2017-06-16 11:06:46 EDT
Anyway the damage has been done, I am sorry for that, I'll try to abstain from enabling previously disabled features of OpenSSL in future.
Comment 6 Lukas Slebodnik 2017-06-16 11:09:42 EDT
(In reply to Tomas Mraz from comment #4)
> This was not the case this time - I've just enabled SRP support because it
> was now allowed by legal.

So IIUC newly added functions are due to optional "SRP support". But in this case
They should be in version OPENSSL_1_1_0_SRP. So linker/rpm can detect it.

Do you think it would be acceptable solution for upstream?
Comment 7 Lukas Slebodnik 2017-06-16 11:10:35 EDT
(In reply to Tomas Mraz from comment #5)
> Anyway the damage has been done, I am sorry for that, I'll try to abstain
> from enabling previously disabled features of OpenSSL in future.

I can happen in any other distribution. So it should really handled properly in upstream.
Comment 8 Tomas Mraz 2017-06-16 11:32:55 EDT
(In reply to Lukas Slebodnik from comment #6)
> (In reply to Tomas Mraz from comment #4)
> > This was not the case this time - I've just enabled SRP support because it
> > was now allowed by legal.
> 
> So IIUC newly added functions are due to optional "SRP support". But in this
> case
> They should be in version OPENSSL_1_1_0_SRP. So linker/rpm can detect it.
> 
> Do you think it would be acceptable solution for upstream?

Yes, I think the resolution should be done in such way. Unfortunately I do not think they will apply it to already released version because it would probably break more things than fix. But for newly introduced optional features it can and should be done.
Comment 9 Lukas Slebodnik 2017-06-16 12:54:05 EDT
Adding curl maintainer to CC; just in case of duplicated report as in Comment 1
Comment 10 Kamil Dudka 2017-06-16 13:09:47 EDT
Thanks for heads up!  Bug #1462184 looks indeed like a duplicate of this one.

Note You need to log in before you can comment on or make changes to this bug.