Timothée Besset, a software engineer who works on the Steam client for Valve, took to Mastodon this week to reveal: “Valve is seeing an increasing number of bug reports for issues caused by Canonical’s repackaging of the Steam client through snap”.
“We are not involved with the snap repackaging. It has a lot of issues”, Besset adds, noting that “the best way to install Steam on Debian and derivative operating systems is to […] use the official .deb”.
Those who don’t want to use the official Deb package are instead asked to ‘consider the Flatpak version’ — though like Canonical’s Steam snap the Steam Flatpak is also unofficial, and no directly supported by Valve.
The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.
This would ensure security, as well as a proper functioning flatpak/snap and also all feedback would be directed to the Dev.
I’ve never liked the fact that Canonical and whoever can make Snaps and Flatpaks of other people’s software. There is zero security guarantee, zero guarantee they’ll update it and zero guarantee it will work.
Just because Snap and Flatpak exist doesn’t mean just anyone should be able to just make them.
If Valve only chooses to make a deb then so be it! It’s their product!
The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.
Says who? If it were the case, Linux would either be a nightmare of fragmentation or become centralised on one distribution. Distros need to be able to package their own software, and these are kind of like distributions. Also since we’re talking about proprietary software here, is it really any better security practice if the “real dev” packages it or somebody else, they both could contain malicious code.
Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.
The distros should stick to packaging their repo apps and leave the Snap/FlatPak tech as an alternative to the original dev if they decide they want to use that.
We can’t have Bob from nowhere packaging Valve, then not updating it or patching it because he doesn’t have time. Or 5 Bob’s all doing the same thing with 5 copies of Valve on the Store.
It’s crazy. This is what causes fragmentation. Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You’re still welcome to make a Flatpak for home use on your own pc but not for wide distribution.
Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.
How would you know that? It’s not like it’s something that doesn’t happen.
Or 5 Bob’s all doing the same thing with 5 copies of Valve on the Store.
It’s crazy. This is what causes fragmentation.
I don’t know what snaps are like but that’s clearly a non-existent problem on Flathub.
Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You’re still welcome to make a Flatpak for home use on your own pc but not for wide distribution.
I don’t know why you feel like there’s permission involved. You don’t have to use Flathub, therefore Flathub can have what ever policies it likes. Users can set up a different flatpak repo if there’s a need.
isn’t that kind of what AUR is, and exactly what people love about arch ?
How so? How does ensuring they only the real dev of the app is also the only one allowed to package it hurt desktop adoption.
It’s very easy to enforce. Flathub need to verify the identity of the person submitting the Flatpak to make sure it’s the app’s dev uploading it and not Joe Smith or nsa.gov…
For security reasons the packaging of flatpaks in flathub is done by flathub, whether they are devs or third parties they just write the manifest. Although I seem to remember there are some exceptions, such as firefox.
Ah, I was not aware of that. Ok, that’s good to hear because it potentially adds a layer of security.
Any idea whether they vet the code as well?
Not that I know of. But you may be interested that it requires prior authorization to modify manifests.
Just to play devils advocate, why don’t they simply officially support the Snap store?
Because it’s the same story as with Mir or Upstart: it will die, because its half assed and tailored to Ubuntu, this time with dubious non-free parts even
Canonical is a joke
It’s too bad. I feel like they’re a versions of Ubuntu from 2006 to, say, 2012 or so, that were beautiful and perfect and were accessible to me as a college student. It set a new standard. It seems like half the battle is having people with good vision making important decisions so things don’t go off the rails.
Don’t they own the Code?
Can’t they just cease-and-desist them if they cause them trouble?
They could and they would if they wouldn’t profit from this in the end,
for some reasons there is no official Flatpak and they don’t want to support a Snap package, they just say anything but the *.deb is unsupported, kinda weird because they use the Flatpak package on Steamdeck because that is Arch-based, i guess they are somewhat involved there.
As much as they do for the Linux movement, they should get their shit together when it comes to a cross-distro client, preferably Flatpak obviously.
Do they use the steam flatpak, or just allow flatpaks to be used? There’s a difference.
guys hear me out. steam os: debian edition
The original SteamOS is based on Debian, https://store.steampowered.com/steamos
I guess backporting everything was a pain.
SteamOS 2.0 which is used on Steamdeck (and only available on Steamdeck officially) has nothing to do with that.
