Magicka 2 Linux x86-64 crashes on start with error messages involving libssl_conf.so

[nipsy]

Your system information

• Steam client version (build number or date): Dec 14 2018, at 22:19:08
• Distribution (e.g. Ubuntu): Debian buster x86-64
• Opted into Steam client beta?: [Yes/No] Yes
• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

Trying to start Magicka 2 for Linux (64-bit version on a 64-bit distribution) fails. While most of the necessary files/symlinks are present in ~/.steam/ubuntu12_32/steam-runtime/amd64/... there seems to be a critical one missing. I expected a natively available Linux game to start without needing to do anything extra.

I've also included a run from the CLI using the necessary Steam runtime wrapper showing the actual reason for the crash (missing libssl_conf.so) at:
https://gist.github.com/nipsy/b3b4e2d315e3300445410919ff800080

Steps for reproducing this issue:

1. Install Magicka 2 under Steam on my 64-bit Linux distribution.
2. Click Play button.
3. Screen goes dark like the game is trying to start.
4. Application crashes and returns to Steam window.

Steps for fixing

A temporary solution if Valve cannot fix this is:

ln -s ~/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0 ~/.steam/steam/steamapps/common/Magicka\ 2/engine/libssl_conf.so

which will create a link in a location that will fix the problem at least. Running from the CLI or using the Play button via the Steam UI both work correctly after doing this.

Ideally, an additional symlink would be created in ~/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu, but I'm unsure if this would negatively impact other games.

[nipsy]

Humorously enough, I found the solution to this via another Paradox Interactive Linux game failing to start correctly at:
https://forum.paradoxplaza.com/forum/index.php?threads/surviving-mars-linux-crash-on-startup-solved.1125237/

[nipsy]

#4837 contains a comment about this very problem also. I'm linking from that bug report to this one also.

[kisak-valve]

Hello @nipsy, for sanity sake, please also try STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 ~/.steam/ubuntu12_32/steam-runtime/run.sh ./Magicka2_x64 (with no workarounds).

[nipsy]

@kisak-valve I've added that CLI output to the original gist above. Seems to fail in exactly the same way. I also had looked previously to see if Debian even provides a libssl_conf.so still, but I didn't find any reference to it via apt-file search (using the standard main, contrib and non-free APT sources for Debian).

[TTimo]

I don't think this is a problem with the steam client or the steam runtime unfortunately, but an issue with Magicka 2.

libssl_conf.so appears to be a module that was part of older libssl distributions, that is no longer available in more recent libssl versions. It was probably never meant to be used directly by client programs. A quick google search seems to support this.

steam runtime never distributed it, and when Magicka 2 worked it must have been by implicitly relying on it being present on the host OS.

This needs to be taken up with the Magicka 2 developers to be properly addressed. I realize compiling updated binaries isn't necessarily practical in a released title, but this may be a simple matter of recompiling using the docker runtime environment from https://github.com/ValveSoftware/steam-runtime/

If there is something else we can do please comment on this issue and we will re-open it.

[TTimo]

Afterthought - I suppose wrapping the legacy binary in a shell script with the adequate workaround could be a cheap way to fix this.

[TTimo]

After further investigation, we think this is happening because the libssl library in the runtime is picking up configuration items from the host's /etc/ssl/openssl.cnf that it can't adequately interpret. So it is indeed a problem on our end .. reopening!

[smcv]

Some research into this:

libssl_conf.so never actually existed on disk. OpenSSL has a complicated approach to configuration, in which /etc/ssl/openssl.cnf configuration parameters cause loading of native-code modules, which can either be built-in to libcrypto or libssl, or real files on disk (like the way Python's sys module is built-in to the interpreter, but its readline module is external). libssl_conf.so is one of several names OpenSSL would try for the ssl_conf module.

Since 1.1.0 (commit 59b1696c), there is a ssl_conf module built-in to libssl. It moved into libcrypto in 1.1.1 (commit d8f031e8).

In Debian, since 1.1.1 (August 2018, if we don't count experimental), /etc/ssl/openssl.cnf has made use of the ssl_conf mechanism to enforce TLS1.2 as the minimum protocol (in response to cryptographic weaknesses in TLS 1.0), and 112-bit security (level 2) as the minimum security level. This file is only installed if the openssl package (containing the openssl command-line tool) is installed. However, ca-certificates depends on openssl, so in practice basically all users will have it. Unfortunately, this new /etc/ssl/openssl.cnf can't be successfully interpreted by the libssl 1.0.0 in the Steam Runtime.

I'm not sure yet how this avoids breaking the libssl 1.0.2 that is still also available in Debian unstable.

[smcv]

@nipsy: If you remove any other workarounds, and run the game with OPENSSL_CONF=/dev/null in the environment, does that also work?

[nipsy]

@smcv Sure enough:

$ cd ~/.steam/steam/steamapps/common/Magicka\ 2/engine; ls -alF libssl_conf.so
ls: cannot access 'libssl_conf.so': No such file or directory
[1]    21018 exit 2     ls -alF libssl_conf.so
$ OPENSSL_CONF=/dev/null ~/.steam/ubuntu12_32/steam-runtime/run.sh ./Magicka2_x64

works great!

[smcv]

Thanks, that's very useful feedback (and probably a better short term workaround too).

[smcv]

Please could someone with appropriate privileges retitle this?

Magicka 2 Linux x86-64 crashes on start with error messages involving libssl_conf.so

The root cause isn't a missing library symlink - it's valid and correct that libssl_conf.so doesn't exist. The problem is that /etc/ssl/openssl.cnf in Debian buster was written for OpenSSL >= 1.1.0, and is incompatible with the OpenSSL 1.0.0 in the Steam Runtime. I think the solution is to patch the Steam Runtime's libssl so it doesn't load /etc/ssl/openssl.cnf by default.

[smcv]

I think the solution is to patch the Steam Runtime's libssl so it doesn't load /etc/ssl/openssl.cnf by default.

This works, and the updated packages should go out in the next Steam Runtime update.

[TTimo]

This is fixed in the latest steam beta runtime.