FS#53836 - [openssl-1.0] Wrong symbol versions

Attached to Project: Arch Linux
Opened by Felipe Contreras (felipec) - Wednesday, 26 April 2017, 05:38 GMT
Last edited by Antonio Rojas (arojas) - Friday, 19 May 2017, 19:36 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 20
Private No

Details

Description:
The symbol versions in the openssl-1.0 package are wrong.

Additional info:
* version: 1.0.2.k-3

Steps to reproduce:

% readelf -a -W /usr/lib/libssl.so.1.0.0 | grep SSL_CTX_new
502: 0000000000041440 1477 FUNC GLOBAL DEFAULT 13 SSL_CTX_new@@OPENSSL_1.0.2d
805: 0000000000041440 1477 FUNC GLOBAL DEFAULT 13 SSL_CTX_new

The version is wrong, it should be OPENSSL_1.0.0.

If you apply Debian's versioning patch, the versioning is correct. I've reapplied the patch to 1.0.2.k, and the versions are correct now.

By applying this patch Spotify works now without any modification or hacks (AUR issue #224927).
This task depends upon

Closed by  Antonio Rojas (arojas)
Friday, 19 May 2017, 19:36 GMT
Reason for closing:  Fixed
Additional comments about closing:  openssl-1.0 1.0.2.k-4
Comment by Antonio Rojas (arojas) - Wednesday, 26 April 2017, 06:43 GMT
There is no concept of "wrong" symbol versions, by default openssl-1.0 symbols are not versioned so every distro is using their own versioning. We are actually using Debian's patch from Stretch, yours is from Jessie. So even Debian is not keeping compatibility between versions.
This patch would fix some stuff now, but as soon as closed source developers start compiling their stuff against Stretch it will break again. In  FS#53618  there is another, more future-proof solution proposed.
Comment by Felipe Contreras (felipec) - Wednesday, 26 April 2017, 08:24 GMT
> There is no concept of "wrong" symbol versions, by default openssl-1.0 symbols are not versioned so every distro is using their own versioning.

So? A distro can do wrong versioning, and Arch Linux is doing so. SSL_CTX_new is found in 1.0.0.

> We are actually using Debian's patch from Stretch, yours is from Jessie.

The version of openssl in Stretch is 1.1.0e, and has no versioning symbols patch. So what are you talking about?

> This patch would fix some stuff now, but as soon as closed source developers start compiling their stuff against Stretch it will break again.

No it won't. SSL_CTX_new@@OPENSSL_1.0.0 will *always* be SSL_CTX_new@@OPENSSL_1.0.0, because that is the correct version. If a program is compiled against SSL_CTX_new@@OPENSSL_1.0.2d by *mistake*, then supposedly only a warning will appear.

Debian has the versioning right.
Comment by Antonio Rojas (arojas) - Wednesday, 26 April 2017, 08:30 GMT
> The version of openssl in Stretch is 1.1.0e, and has no versioning symbols patch. So what are you talking about?

I am talking about this https://packages.debian.org/stretch/libssl1.0-dev
Comment by Laurent Carlier (lordheavy) - Wednesday, 26 April 2017, 09:28 GMT
Tried the patch with Shadow of Mordor and it works fine
Comment by Jan de Groot (JGC) - Wednesday, 26 April 2017, 10:55 GMT
Debian has multiple versions of OpenSSL:
- libssl1.0.0: libssl.so.1.0.0 with symbol versions at 1.0.0
- libssl1.0.2: libssl.so.1.0.2 with symbol versions at 1.0.2
- libssl1.1: libssl.so.1.1 (don't know about symbol versions)

What we have:
- openssl-1.0: libssl.so.1.0.0 with symbol versions at 1.0.2
- openssl: libssl.so.1.1 (don't know about symbol versions)

Debian chose to package OpenSSL 1.0.2 for Stretch with a bumped soname version and bumped symbol versions. For jessie-backports they decided to keep 1.0.0 soname and 1.0.0 symbol versions.

IMHO our package is highly incompatible with Debian. Either we bump soname to 1.0.2 or downgrade symbol versions to 1.0.0 by taking the symbol versioning patch from jessie-backports. Note that both ways will break either soname or ABI and requires a recompile of everything that was compiled against our current openssl-1.0 package.

Edit:
Fedora uses libssl.so.10 for their OpenSSL 1.0.x packages. library versions are mixed 1.0.1 and 1.0.2.
Comment by Felipe Contreras (felipec) - Friday, 28 April 2017, 08:00 GMT
Well, the whole situation is a mess, and all because openssl 1.0 didn't version their symbols. From what I can see openssl 1.1 does have symbol versioning upstream, so this shouldn't be a problem in the future.

If they had done symbol versions in openssl 1.0, they would have SSL_CTX_new@@OPENSSL_1_0_0, since it was available since 1.0. That's what happening for 1.1; there is SSL_CTX_new@@OPENSSL_1_1_0. When they release 1.1.2 the symbols specific to that version would be foo@@OPENSSL_1_1_2, but the old ones like SSL_CTX_new would be OPENSSL_1_1_0.

IMO whoever decided to use OPENSSL_1.0.2d for symbols present since 1.0 made a mistake.

So it seems the two options are a) use the wrong version (OPENSSL_1.0.2d) for ever and ever, or b) use the correct version (OPENSSL_1.0.0) and require rebuilding.

I'm not so sure which is best anymore, but I don't think the current situation is ideal.
Comment by Oliver Mangold (omangold) - Sunday, 30 April 2017, 12:21 GMT
I can confirm that these symbols are a problem. I would like to add that some proprietary executables also depend on the old behavior. For example I cannot run Deus Ex: MD anymore since the change:

---
>>> Adding process 10904 for game ID 337000
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
===
ERROR: ld.so: object '/home/hpcmango/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/hpcmango/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/hpcmango/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libldap_r-2.4.so.2: no version information available (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/liblber-2.4.so.2: no version information available (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
--
Comment by Mantas Mikulėnas (grawity) - Saturday, 06 May 2017, 12:14 GMT
Re-using Debian's patch would be best, since a lot of such software is built against either Debian or Ubuntu libraries. (libclassicclient here requires OPENSSL_1.0.0 and OPENSSL_1.0.1, for example.)
Comment by TesX (tesfabpel) - Saturday, 06 May 2017, 16:29 GMT
Some proprietary software don't work anymore (eg. some Steam games, JetBrains Toolbox)...
Since we only have control over open-source software, I think the best option is to do as how Debian does, and rebuild all Arch's packages.
BTW, as I said in the other bug report (https://bugs.archlinux.org/task/53618#comment157324), by using setting LD_LIBRARY_PATH and using the AUR package libopenssl-1.0-compat, Jetbrains Toolbox works again...

PS: Jetbrains Toolbox can be downloaded for free from the jetbrains website and it doesn't require an account, if anyone wants to verify if the patch works...
Comment by Oliver Mangold (omangold) - Tuesday, 16 May 2017, 11:07 GMT
Wouldn't it help to build it the same way as Debian, meaning having two 1.0.x libraries with different symbol versions:

- libssl.so.1.0.0 with symbol versions at 1.0.0
- libssl.so.1.0.2 with symbol versions at 1.0.2

?

Loading...