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:
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
I am sorry, but I do not want to diverge from upstream on the symbol versions.
(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.
This was not the case this time - I've just enabled SRP support because it was now allowed by legal.
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.
(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?
(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.
(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.
Adding curl maintainer to CC; just in case of duplicated report as in Comment 1
Thanks for heads up! Bug #1462184 looks indeed like a duplicate of this one.