Steam Runtime 4 can't use libcurl on Ubuntu 24.04 LTS

[vectorstorm]

Your system information

• Steam client version : 1778281814
• Distribution (e.g. Ubuntu): Ubuntu 24.04 LTS
• Opted into Steam client beta?: No
• Have you checked for system updates?: Yes
• Steam Logs: n/a
• GPU: NVidia

Please describe your issue in as much detail as possible:

A report from one of our players sent me down this rabbit hole and I think I've chased it as far as I can. We've recently migrated our Linux build to Steam Runtime 4, and a user who is still running Ubuntu 24.04 LTS cannot run our game any more. They get these error messages:

/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libcrypto.so.3: version OPENSSL_3.3.0' not found (required by /lib/x86_64-linux-gnu/libssl.so.3)
/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libcrypto.so.3: version OPENSSL_3.4.0' not found (required by /lib/x86_64-linux-gnu/libssl.so.3)
/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.2.0' not found (required by /lib/x86_64-linux-gnu/libssl.so.3)

And then the game fails to launch.

After installing a fresh copy of Ubuntu 24.04 LTS on a test PC, I've confirmed that I get these same error messages. Our various test machines with more recent distros do not have this problem; it works across Arch, CachyOS, SteamDecks, AnduinOS, and a few others.

I have repro steps which don't require our game, though; only tools that ship with the container:

Steps for reproducing this issue:

1. On an Ubuntu 24.04 LTS machine, with Steam and the Steam Linux Runtime 4 installed in default locations, run the following command in terminal: sudo ~/.steam/steam/steamapps/common/SteamLinuxRuntime_4/run xterm (you require 'sudo' in order for the runtime to successfully run bwrap, as Canonical restricts who is allowed to invoke that program in 24.04 LTS. You can omit the 'sudo' if you reconfigure AppArmor to allow unprivileged access)
2. Inside this xterm, run the command curl. (or any other executable that links against libcurl, but 'curl' itself is easiest for testing since the runtime already includes it!)
3. Notice you get the three error messages above, about OPENSSL_3.3.0, OPENSSL_3.4.0, and OPENSSL_3.2.0 (in that order) not being found.

I don't know why this error is only happening on Ubuntu 24.04 and not on other (more recent) distributions; I'm guessing that somehow execution is escaping from the runtime container and talking to the native distribution's crypto libraries instead of the container's more recent ones, which would explain how/why it fails on Ubuntu 24.04 but not on more recent distributions?

[smcv]

For your information, an easier and less sudo way to get a shell inside a game container is to launch a SLR 4 game with its Steam launch options set to PRESSURE_VESSEL_SHELL=instead %command%. Maelstrom is a convenient example of a free game that runs in SLR 4.

[smcv]

/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libcrypto.so.3: version OPENSSL_3.3.0' not found (required by /lib/x86_64-linux-gnu/libssl.so.3)

At a high level, the problem is that something in the graphics stack (we can't yet tell what from the information available here) has a dependency on OpenSSL libcrypto. The graphics libraries could legitimately stop working if they don't have at least their required libcrypto, and application libraries (like libcurl and your game) could legitimately stop working if they don't have at least their required libcrypto, so we need to choose which one of those libcrypto instances is newer. If the host version is newer, we make it available in /usr/lib/pressure-vessel/overrides/, and if the container version is newer, we don't do that. In principle, this should hopefully work.

However, something has gone wrong here. If I'm reading correctly, https://launchpad.net/ubuntu/+source/openssl says that Ubuntu 24.04 has OpenSSL 3.0.13, while https://tracker.debian.org/pkg/openssl says that Debian 13 (and therefore steamrt4) has OpenSSL 3.5.x. Therefore we should be choosing the container's version; but we aren't.

The result is that when curl loads OpenSSL libssl, which loads OpenSSL libcrypto, we have libssl version 3.5.x but libcrypto 3.0.13, which is far too old, hence missing symbols.

There are two angles that we can attack this from:

• We're somehow identifying Ubuntu 24.04's OpenSSL 3.0.13 as being newer than or equal to steamrt4's 3.5.x, which is not true. My guess would be that we are unable to identify either one as being newer than the other, which means we fall back to assuming the host version is newer, because until recently that has usually been true. If we can teach the container machinery to identify their relative versions better, then we should be able to decide that 3.5.x is newer than 3.0.13.
• And, Ubuntu 24.04's graphics stack somehow depends on OpenSSL libcrypto, which seems odd: I would not have expected a graphics stack to depend on cryptography libraries. Perhaps we can identify why, and ask for it to not do that?

GPU: NVidia

I wonder whether this is libnvidia-pkcs11-openssl3.so.*, which is treated as part of the graphics stack but certainly does depend on libcrypto. Perhaps we should denylist the libnvidia-pkcs11* libraries as not really being "graphics": as far as we know, they're for "confidential computation", which is more of a CUDA/GPGPU thing than a gaming thing, and OpenSSL-related breakage like this is a pretty bad impact for a library that we're not even sure we need.

Taking this particular library from the host was broken for a while, until I fixed it in https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/925 in the hope that it might help to resolve #799.

cc @ao2: see also steamrt/tasks#1035, steamrt/tasks#914 internally.