Requires old libpng and libtiff libraries

[shoober420]

Your system information

https://gist.github.com/shoober420/1215c40214cf70e1fabb760b5bd2a341

• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

CSGO requires legacy versions of libpng (1.2.59) and libtiff (3.9.7) for it to start, even when the latest versions of these libraries are installed (1.6.37 and 4.0.10). Its detrimental for performance and security for software to require old libraries.

Steps for reproducing this issue:

1. Uninstall legacy versions of libpng and libtiff
2. Keep recent up to date versions of libpng and libtiff installed
3. CSGO still doesnt start

[shoober420]

I know that some games do require some old libs, like the legacy version of OpenSSL (1.0.2.r-1), but CSGO is such a high profile game aimed towards online play, so it’s unacceptable to have it using old libs. It’s opening the door to exploits.

I know this is why the Steam runtime is a thing to begin with, but some games needing older libs isn’t that big of a deal, since most aren’t even online or that high of profile as CSGO is. But high profile online multiplayer games need to be safe guarded by keeping the dependencies up too date.

[sylware]

something is weird since those libs should be in the steam runtime. Even though, the "right way" to deal with the issue is: statically link those libs into csgo, but if the lib is badly designed and don't support static linking, the shared lib should be distributed with csgo binary and the csgo starting sh script should overload the LD_LIBRARY_PATH in order for the linux dynamic elf loader to find the distributed shared libs.

[kiroma]

The steam runtime does contain libpng 12, however it's the 1.2.46 version from 8 years ago. The problem isn't with portability, the Steam Runtime provides that. It's the many issues that come from using old, unmaintained versions of a library.

[sylware]

The only system things games do care about are input APIs(x11/wayland/native linux event), WSI APIs(x11/wayland), 3D APIs(GL/vulkan), sound APIs(alsa/pulse). For that, they only need the system libc/elf dynamic loader since they should dynamically discover those APIs and cherry pick what they use in them. All the rest is internal/private to the games: they could use a libpng or libtiff from 2 centuries ago, that would not matter. On gnu systems, there are the additional pitfalls of libstdc++ and libgcc, but it can be worked around with gcc -static-libgcc -statc-libstdc++ options. Game developers should always build their packages in a chroot, that to account for all system deps properly they could have missed or they could end up with a package only working on the massive gnu/linux distro they use (in current era: ubuntu).

[shoober420]

@sylware

Software that requires old libs is never good, no matter how “private” you think they are on your system. Even if you feel using old libs on your system is safe, and that you think it’s “private” enough, the other issue is performance.

Using old libs will be detrimental performance wise as well. If a piece of software requires certain libs, even if they are higher level than the lower level things like Graphics APIs and Input APIs you mentioned, that doesn’t mean they can’t be exploited because you think they are “private”.

[sylware]

if it's internal to the game, it's up to the devs of this very game to use the latest version, or the version of 2 centuries ago.

[shoober420]

If these libs were internal to the game, I wouldn’t need to manually install libtiff4 and libpng12 to begin with (or depend on the Steam runtime).

Also I should mention, I have the Steam runtime disabled.

[sylware]

The steam runtime can be considered "kind of internal" to games deployed via steam on gnu/linux OSes. It is far from perfect since there are many potential conflicts between trees of dependencies of libs/bins installed on the user system and the libs/bins steam runtime. To mitigate such conflicts the steam runtime implements "lib pinning" (but in an horrible bash only script). The worst conflicts are the endless issues with libstdc++ and libgcc.

For you, I would recommend to re-enable the steam runtime and try to figure out any conflicts with "lib pinning".

IMHO, the only definitive answer would be to prepare a "gnu/linux steam runtime V2" which would be... empty... It's with a "gnu/linux steam SDK v2" that real improvments could be made based on what I already said (and a bit more): gcc -static-libgcc -static-libstdc++ (for those using c++), sh scripts at best (no bash) with a minimal set of posix commands, the set of game bins and internal shared libs should have dynamic dependencies trees which leaves are only dependent on user system glibc/elf loader, and everything else dynamically discovered with cherry picking. The steam SDK could provide plumbering code to perform the most annoying functionalities to help game devs, not to mention libSDL2 is almost doing everything I said. To "show the way", valve would have to do it first with its client, but I know what "corporate code" means... poor devs...

[shoober420]

Creating another runtime is pointless, and going in the wrong direction.

The best solution, would be how Arch does this, which is create a "package" that directs and pulls the required libs for the Steam client and games, and have them installed.

Depending on the Steam runtime for games and the client to function, is pure laziness, and is only there for convenience. The reason people choose to disable the Steam runtime, is the fact it uses older libs. This is bad for security and performance.

If Valve kept the Steam runtime libs more up too date, some may choose to leave it enabled, but this is not the case. It does indeed use older libs than what Arch uses for example. Arch is bleeding edge, and uses the latest versions of packages than just about any other distro out there. This is the main reason people use Arch, its bleeding edge.

Using a bleeding edge distro, but using the Steam runtime along with it is a whole contradiction to use Arch, or any relatively bleeding edge distro to begin with, and diminishes the whole point of bleeding edge.

[sylware]

creating another runtime is pointless, and this is what I wrote: "empty runtime"

... but a good SDK with good and simple guidelines (which I describe partly in my previous post) should do the trick. It narrows down to education (as usual...)

this SDK and guidelines would make closed source binaries (steam client and games) stellar robust on gnu/linux OSes (and actually, on the other OSes too)

even though, conflicts still can happen if video game core user system libs pull in games/steam client processes dependencies which conflict with games/steam client "internal" libs (today, we can presume it's the steam runtime). That's why static linking should be really prefered, but it's not always possible (should be rare though)

this is a bird eye perspective, don't forget that devil hides in the details

for instance, many open source libs pretend to be ABI stable (GNU lib numbering scheme), but aren't actually for various reasons

[shoober420]

Users who disable the runtime don’t have to worry about “internal” libs. Steam will then use the libs that are installed on the clients system.

[sylware]

as I said in my previous post: devil hides in the detail.

due to many open source libs "lying" on their ABI stability, this is not a reasonable option for binaries.

not to mention the other points in my previous posts which are as important or even more.

[shoober420]

@sylware Have you ever ran Steam without the runtime?

[sylware]

As I stated in my previous posts, the steam runtime has a "lib pinning" system (unfortunately coded in bash) which allows you to override some libs from the steam runtime. This "lib pinning" system tries to select "more recent" versions of some libs with the act of faith that their ABI was stable (actually the "ABI" which is represented by the whole dependency tree). On my system, the steam runtime without pinning the x11 related libs won't work. In the other hand, my system does not include by far all the libs from the steam runtime. This is one of the reasons to go for a dynamic discovery of the video game core libs with cherry picking what it is used, and to perform as much as possible static linking. This is more work, but it's clean and will give a stellar boost in robustness on a large spectrum of gnu/linux distros.

[shoober420]

@sylware

I’m going to take your answer as a no to my question.

If CSGO did indeed bundle libpng and libtiff internally like you’ve been saying, it would have no issue starting up with libpng and libtiff uninstalled from the system along with the runtime disabled.

Since I have the runtime disabled, I could careless about “lib pinning” or how the runtime works. It’s of no concern to me, or anyone else who has the runtime disabled. Disabling the Steam runtime ensures the Steam client, and Steam games are using the latest libs on the system.

Until you actually run Steam without the runtime, you have no say in this discussion. Making an assumption that CSGO has these libs internally, doesn’t mean you are correct. Stating such a theory doesn’t make you right, no matter how many times you repeat it or mention you’ve said it.

[sylware]

Each case is different: it depends on the dependency tree and ABI compatibility for each closed source program.

Due to the very reasons I did already post, and the current state of the steam distribution and steam games: unfortunately expecting any close source program to run without the steam runtime (which is "internal") is an act of faith. For the moment, the steam binary env is the steam runtime + pinned libs

• a few user system libs. Even with that, there can be some conflicts. To minimize those conflicts and going stellar robust on nearly all gnu/linux distros out there (it is valid for the other OSes too): "static linking/dynamic discovery and cherry picking".

[shoober420]

I disagree, I’ve been running without the runtime successfully for over half a decade. You simply have to know what you’re doing.

[sylware]

This is wrong reasonning: you are making your personal case a generality to all, namely many gnu/linux users out there were not as lucky than you: don't forget there are many games and many gnu/linux distributions of various sizes and configuration. A target of closed source programs (games and steam client) is to maximize their compatibily within reasonable technical boundaries over a maximum amount of time. What I previously posted are guidelines to help achieve this goal.

[shoober420]

No, if you read through the Arch wiki, install the right dependencies for the Steam client and it’s games, you can use Steam without the runtime. It’s pretty simply actually, even Arch has its own package specifically for this, to make it more easy.

It’s not that difficult, really. If it happens to be difficult for you, this would explain why you’re an Ubuntu user.

[sylware]

You should understand that ABI issues are real on the large spectrum of massive and light gnu/linux distros. What I did describe is kind of universal, it's gnu/linux distro agnostic... actually it common sense for any OSes.

[shoober420]

@sylware

You say “kind of” a lot, and use Ubuntu. Why are you here?

[shoober420]

Oddly enough, L4D2 and Portal 2 do not require these old libraries too run. Straaaaaaaaaaaaaange.

[shoober420]

Legacy libpng vulnerabilities.

https://www.cvedetails.com/vulnerability-list/vendor_id-7294/Libpng.html

Legacy libtiff vulnerabilities.

https://www.cvedetails.com/vulnerability-list/vendor_id-2224/Libtiff.html

[romanstingler]

@kisak-valve this can be closed