Valve seeing increasing bug reports due to Steam Snap - other methods recommended

Quoting: Fester_MuddValve could start collaborating with Canonical for the snap package. Also with who creates the flatpak mutually. These packaging formats are the present and future of Linux app packaging.

AppImage is just not it: they don't integrate with the system, don't have an automatic update by default and they need to be made executable manually (this is already too much for normal users).

This is not that much of a Canonical or a Ubuntu issue though as this same could happen easily with flatpak.

Flatpak cannot handle CLI and server side stuff for the record but snaps can. That said we have managed to narrow the packaging methods kinda to only 2. Snap and flatpak it is. Kind of like MSI and EXE in Windows world, i suppose.

Ultimately I think the best way to go about all of it is to have a mix. It is much more difficult for a distribution (and in this case most are community supported) to have 'official' repositories for the vast majority of software that can be the supported side, and then you have software that needs to be newer, installed via methods like Flatpak. Perfect example of this is Debian. They do not package normal Firefox for their Stable releases. Instead they have Firefox-ESR. If you want current Firefox, use their official flatpak.

Steam doesn't make much sense to do that, as the steam installer script installs it in the correct places, then sets up all the things in your home directory, and self-updates the bits there.

Quoting: Kimyrielle

Quoting: TiZNot even one? I have an easy one. First, Steam is proprietary. Valve does do a lot of great FOSS work, and they are generally trustworthy, but Steam itself is still proprietary at the end of the day. And it has made catastrophic mistakes before. Containerizing it limits the scope of the damage it can possibly do.

That's not it, either. I have about... 800+ additional reasons, at least in my Steam library. A whole litany of proprietary, closed-source games. Only a fraction of them are native, and would have hypothetically unfettered access to the whole filesystem when unsandboxed, but that's enough to prefer to be safe rather than sorry. Steam does have its own container runtimes, Soldier and Sniper, but most native binaries don't use them. Proton is their main consumer, actually.

I love open source software as much as anyone, but let's be real here. There are plenty of super serious bugs in OSS applications, too. Saying that anything proprietary is untrustworthy by design is a bit over the top. With your logic, you'd need to containerize EVERYTHING, and the result of this would be a a fairly unproductive and ineffective system. I get containerization for high-risk applications (yes, like the internet browser), but locking software from trustworthy vendors inside a container is a bit much on the paranoid side.

I didn't read the whole comment thread, but let me give you a more specific example: try to play an online match of Unreal Tournament 1999 (on Steam). It will download a few DLLs from the server when connecting, then happily execute whatever code is inside. Remote code execution by design! Great for server-provided mods, isn't it?

As someone wrote above, games are usually not written with security in mind, especially decade-old games. They often connect to the network, and are quite often never updated past release, except maybe to fix game breaking compatibility issues. I believe even Steam is looking into containerizing games (possibly with thermal Linux runtime?), even on Windows.

Quoting: MayeulC

Quoting: Kimyrielle

Quoting: TiZNot even one? I have an easy one. First, Steam is proprietary. Valve does do a lot of great FOSS work, and they are generally trustworthy, but Steam itself is still proprietary at the end of the day. And it has made catastrophic mistakes before. Containerizing it limits the scope of the damage it can possibly do.

That's not it, either. I have about... 800+ additional reasons, at least in my Steam library. A whole litany of proprietary, closed-source games. Only a fraction of them are native, and would have hypothetically unfettered access to the whole filesystem when unsandboxed, but that's enough to prefer to be safe rather than sorry. Steam does have its own container runtimes, Soldier and Sniper, but most native binaries don't use them. Proton is their main consumer, actually.

I love open source software as much as anyone, but let's be real here. There are plenty of super serious bugs in OSS applications, too. Saying that anything proprietary is untrustworthy by design is a bit over the top. With your logic, you'd need to containerize EVERYTHING, and the result of this would be a a fairly unproductive and ineffective system. I get containerization for high-risk applications (yes, like the internet browser), but locking software from trustworthy vendors inside a container is a bit much on the paranoid side.

I didn't read the whole comment thread, but let me give you a more specific example: try to play an online match of Unreal Tournament 1999 (on Steam). It will download a few DLLs from the server when connecting, then happily execute whatever code is inside. Remote code execution by design! Great for server-provided mods, isn't it?

As someone wrote above, games are usually not written with security in mind, especially decade-old games. They often connect to the network, and are quite often never updated past release, except maybe to fix game breaking compatibility issues. I believe even Steam is looking into containerizing games (possibly with thermal Linux runtime?), even on Windows.

On the bright side of that, this would be ran via Wine, which itself is sort of sanboxed in ways where you'd still have a separate folder structure that particular install is only aware of. So the most that would be trashed is the install directory of that particular game.

Could the sandboxing of that be better? Certainly. But can you make it so the rest of your filesystem is invisible to it? Pretty sure you can.

Quoting: slaapliedjeOn the bright side of that, this would be ran via Wine, which itself is sort of sanboxed in ways where you'd still have a separate folder structure that particular install is only aware of. So the most that would be trashed is the install directory of that particular game.

I think Proton still maps Z: to / for game prefixes. I would assume Windows malware would happily make a target of that.

Quoting: whizse

Quoting: slaapliedjeOn the bright side of that, this would be ran via Wine, which itself is sort of sanboxed in ways where you'd still have a separate folder structure that particular install is only aware of. So the most that would be trashed is the install directory of that particular game.

I think Proton still maps Z: to / for game prefixes. I would assume Windows malware would happily make a target of that.

Yeah, what I was saying is it doesn't 'have to'. It's definitely something you can turn off in wine. Might be worthwhile to see if it does and request that it stop.