gstreamer:0.10 is being removed

[chewi]

It is old, maintained, and vulnerable so it is being removed from the main Gentoo tree. This is a problem because esteam has it in the database and games generally do not bundle it as it is part of the Steam runtime. We have two choices.

1. Copy 0.10 (just gstreamer and gst-plugins-base) to the overlay. I don't like this idea very much but at least it'll still be built from source.

2. Stop setting STEAM_RUNTIME=0 even when the steamruntime flag is disabled. I think we can do this now that STEAM_RUNTIME_PREFER_HOST_LIBRARIES is enabled by default. It would help in some other cases too. I don't think it would break anything. Perhaps some people would like to avoid the runtime altogether but if you have all the necessary libraries then it will never be used anyway. If you don't, well the game just won't start!

Any thoughts?

[Tele42]

Hello @chewi, I do not like the second choice and would rather the useflag be masked much more than lying to the user.

A third option could be for esteam to match gst-0.10 libraries to a fake package which is a stub that prints a security warning when it's encountered (not removing the game-bundled variant). It could also tell the user to contact the game dev and politely request the game be updated.

What games are known to use gst in the wild? We might be able to just drop support without penalty.

[chewi]

While I understand your sentiments about the second option, this situation is unlikely to get any better. We already rely on other old libraries like libgcrypt, though we've managed to hang onto that one for the time being.

That third option sounds like too much work and upstream will almost certainly not be interested, especially as that is still the version provided in the runtime.

I don't actually know of any games that use gstreamer, it's probably very few. I think I'd rather choose the first option than drop support altogether though.

I just wish I knew what Valve's long term game plan is here, if they even have one. They don't appear to have shown any interest in fixing vulnerabilities in versions that upstream have abandoned. Even if they ignore the vulnerabilities, at some point they are surely going to need a new runtime and presumably newer games will be built against that but what of the older games? It seems unlikely that they would have all the developers rebuild (and possibly recode) their games but I've also never heard of Valve dropping old games before.

[Tele42]

Just so that it was clear, I was suggesting we simply drop gst-0.10 and stop trying to unbundle it as well. Looks like I mentally skipped getting that to the keyboard.

If we get users complaining later, then we can decide how to proceed then, which might be telling the user to use the steam runtime for that game.

I'm not opposed to the first idea.

[Tele42]

Okay, so an IRC user reported that older wine bottles are linked against gst-0.10 with:

ldd winegstreamer.dll.so
         linux-gate.so.1 (0xf77bd000)
         libwine.so.1 => /usr/lib32/libwine.so.1 (0xf7562000)
         libgstapp-0.10.so.0 => /usr/lib32/libgstapp-0.10.so.0 (0xf7553000)
         libgstreamer-0.10.so.0 => /usr/lib32/libgstreamer-0.10.so.0 (0xf744d000)
         libgobject-2.0.so.0 => /usr/lib32/libgobject-2.0.so.0 (0xf73ee000)
         libgmodule-2.0.so.0 => /usr/lib32/libgmodule-2.0.so.0 (0xf73e8000)
         libgthread-2.0.so.0 => /usr/lib32/libgthread-2.0.so.0 (0xf73e5000)
         libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0 (0xf72b7000)
         libpthread.so.0 => /lib32/libpthread.so.0 (0xf729b000)
         libc.so.6 => /lib32/libc.so.6 (0xf70f0000)
         libdl.so.2 => /lib32/libdl.so.2 (0xf70ea000)
         libgstbase-0.10.so.0 => /usr/lib32/libgstbase-0.10.so.0 (0xf707e000)
         libxml2.so.2 => /usr/lib32/libxml2.so.2 (0xf6efc000)
         libm.so.6 => /lib32/libm.so.6 (0xf6ea8000)
         libffi.so.6 => /usr/lib32/libffi.so.6 (0xf6e9f000)
         libpcre.so.1 => /usr/lib32/libpcre.so.1 (0xf6e27000)
         /lib/ld-linux.so.2 (0x5662b000)
         libicuuc.so.58 => /usr/lib32/libicuuc.so.58 (0xf6c77000)
         libz.so.1 => /usr/lib32/libz.so.1 (0xf6c5e000)
         libicudata.so.58 => /usr/lib32/libicudata.so.58 (0xf535b000)
         libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/32/libstdc++.so.6 (0xf5169000)
         libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/32/libgcc_s.so.1 (0xf514d000)

 lddtree winegstreamer.dll.so 
 winegstreamer.dll.so => ./winegstreamer.dll.so (interpreter => none)
     libwine.so.1 => /usr/lib32/libwine.so.1
         libdl.so.2 => /lib32/libdl.so.2
             ld-linux.so.2 => /lib64/ld-linux.so.2
     libgstapp-0.10.so.0 => /usr/lib32/libgstapp-0.10.so.0
         libgstbase-0.10.so.0 => /usr/lib32/libgstbase-0.10.so.0
         libxml2.so.2 => /usr/lib32/libxml2.so.2
             libicuuc.so.58 => /usr/lib32/libicuuc.so.58
                 libicudata.so.58 => /usr/lib32/libicudata.so.58
                 libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/32/libstdc++.so.6
                 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/32/libgcc_s.so.1
             libz.so.1 => /usr/lib32/libz.so.1
     libgstreamer-0.10.so.0 => /usr/lib32/libgstreamer-0.10.so.0
     libgobject-2.0.so.0 => /usr/lib32/libgobject-2.0.so.0
         libffi.so.6 => /usr/lib32/libffi.so.6
     libgmodule-2.0.so.0 => /usr/lib32/libgmodule-2.0.so.0
     libgthread-2.0.so.0 => /usr/lib32/libgthread-2.0.so.0
     libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0
         libpcre.so.1 => /usr/lib32/libpcre.so.1
     libpthread.so.0 => /lib32/libpthread.so.0
     libc.so.6 => /lib32/libc.so.6

That effectively takes my option off the table.

[chewi]

I'm confused. Some "Linux" Steam games use Wine?

[Tele42]

Game devs do have the option of wine-wrapping their game and claiming official support. This is bundled on a per-game basis and in general is frowned upon by the community, but it definitely is a thing.

[anyc]

Hm, maybe adding a dummy lib would do as well if they do not actually use the gstreamer functionality?