I am the main developer of Heroic Games Launcher and we used to have a version available on the Snap Store for a while that we needed to unpublish since it was giving several errors since the Proton compatibility layer was not working correctly and this was making Heroic pointless for most people.
Now that we have the steam-support plug I wonder if it could fix those past issues with Proton since Heroic need access to some of Steam features for it to work properly.
I just tried to publish the upcoming Heroic version 2.19 but got blocked on the review because I added the steam plug:
`human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (heroic, steam-support).
Heroic on Snap is something that several of our users request and I and other team members had put several hours into making it work but without success so far.
Note that as a last resort you can also make the steam-support interface available for usage by publishing the snap via external channels(e.g. GitHub Releases), declaring the interface in the plugs section of the Snapcraft project file, and require the user to manually connect the interface after detecting the missing of the connection. This will also disable the auto-update mechanism so you’ll also need to implement update checking functionality if not already available.
With Heroic, we are talking about an upstream that is not only verified but deeply respected within the community. Setting aside web browsers, it’s a top-5 app in downloads on Flathub—exceeding five million according to the store’s own data. While we all appreciate Snapcraft’s security standards, if we want it to be a viable powerhouse for gaming, we must start looking beyond Steam. A native GeForce Now application was announced for Ubuntu just a few days ago, which I assume will also have its own Snap eventually. Furthermore, Epic Games and GOG seem to be viewing Linux more favorably lately. I believe this issue should be addressed now, leveraging Heroic’s renewed interest in upstream. The world of gaming promises to be even more crucial for the growth of GNU/Linux in 2026.
In that case I would suggest implementing a new snapd interface specifically for this application. A pull request to the snapd project would be a good start.
It won’t, however, it will be semantically proper if Steam is the only consumer of a confinement plug called steam-support.
IMHO, all most *-support plugs are snapd developers shoehorning snap confinement so that a certain Canonical-deemed-important application to be runnable as a snap, they are only meant to be a stop-gap solution.
So I imagine the most that can be done is to change the name.
I know they try to prevent apps from accessing various system things for security reasons, but the desired security is utopian.
For example, the home plug gives access to the $HOME folder, and it’s automatically connected to any app. If someone wanted to do something wrong with users’ files, the home plug could be enough.
And if access to the $HOME folder were considered a huge problem, forcing apps to always use the XDG Desktop Portal, it would force many apps to change their code just to do something that should be simple. It would greatly increase security, but it would make the user and developer experience with Snap apps absurdly worse.
It’s precisely these limitations that drive developers away from Snap, even though Snap itself is capable of supporting the apps they create.
Also it is still more secure than classic DAC confinement as leading dot-files are explicitly disallowed which prevent bad actors from stealing users’ SSH/PGP private keys.
The idea is to make it easier for the users, not more complicated.
The whole idea of Heroic is that people can just install it, download their games, hit play and play.
Even though it is possible to tinker with it, we try to avoid it as much as possible, especially now with so many new people entering the linux gaming world.
So, if people need to run some terminal command to make Heroic to work, we would just skip that. Especially since we already distribute both the AppImage and the .deb.
I’m not a store reviewer nor a snapd developer but I understand the concern. IMHO, you’ll need to work with the snapd team for a solution if you want to get similar access as with Steam.
Please, don’t get me wrong but what is the point, from the security point of view, of denying certain access to legitimate OpenSource applications that are built only with OSS technology under a 100% FOSS license and that can be audited by simply anyone and have never ever had a security breach of some kind.
But at the same time giving totaly full machine access to a closed source software like Steam? And, I mean, I love Steam and everything that they do for the linux community. But they are 100% closed source with the exception of Proton and some other tools.
So, no one can audit Steam besides themselves, am I wrong?
On the other hand, anyone can audit Heroic or other FOSS softwares like Lutris, Minigalaxy and so on.
I would never question the legitimacy of Steam, but Snap making decisions that gatekeep other softwares will make more harm to the Snap store than anything else.
But ofc, these are just my two cents, if you guys see that it is not possible, then we will find other ways, even though we don’t want to limit the features that the players has already when using other distribution packages like the ones we already distribute.
Personally I think pragmatism is worthwhile for everyone here.
The upstream maintainers are commited to making this work; and the community stands to benefit from it. We regularly grant classic confinement based on trust alone and this is lesser than classic. If I’m a user on this application, my primary trust concerns aren’t around sandboxing $HOME- it’s the fact they can steal my user credentials instantly and all your accounts associated value. The sandbox already doesn’t prevent this, so it’s arguable what good it is against theoretical attacks in the first place and therefore, why not expand it enough to make the functionality properly shine given trust is already in place. Arguably there’s scope for privilege escalation; but we’re talking curated sources with paid licenses with thousands of other users. It’s not realistic of users to ever experience relative to things simply not working.
If Ubuntu Core Desktop can’t run non-snap apps, then we’re limiting huge potential there long term.
Why push people to third party PPA’s and Flatpak for something snap can do just as well?
The problem here is that steam-support grants close to full classic access to the snap while the launchers will only need a subset of the access (please see the comments in the steam-support source), the proper solution is to identify which access the launchers actually need and to craft a proper interface for this based on that data (i.e. game-launcher-support or whatnot) so that a launcher can not i.e. wipe your HDD due to a malicious game or hook a key logger into your desktop session just because the interface allows to do so (even though the app would never need this access, the interface does currently grant it)… the steam-support and docker-support interfaces have not been limited to their respective applications from day one on just for fun … and the documentation clearly says that they will not be allowed to be used with anything else than these snaps.
If instead of raising this for now 6 weeks across pretty much (felt) every second topic, someone went ahead and started a PR with a basic skeleton people could build on, we might by now even have such an interface …
I already tested Steam Snap, and it can’t properly access my HDDs without the removable-media plug connected; in other words, the steam-support plug doesn’t offer that much freedom.
The test basically consisted of removing the removable-media plug connection, adding the HDD to Steam, and trying to download a game onto it; it resulted in an error.
And in any case, that justification doesn’t make sense, since Steam Snap has an automatic connection with the removable-media plug, and Steam can even run .exe files from unknown sources.
If you didn’t understand, if something malicious happens, it will probably be the user’s own fault.
