- name: minigalaxy
- description: A simple GOG client for Linux
- snapcraft: Snap-Minigalaxy/snapcraft.yaml at main · Kyuyrii/Snap-Minigalaxy · GitHub
- upstream: GitHub - sharkwouter/minigalaxy: A simple GOG client for Linux
- upstream-relation: I only made the Snap version
- interfaces:
- <interface-name>: joystick
- request-type: auto-connection
- reasoning: It is necessary for the user to be able to interact with the games using the gamepad.
- <interface-name>: steam-support
- request-type: auto-connection
- reasoning: It is necessary to ensure that Wine will work correctly when added, as well as when/if UMU launcher support is added, there is already a pull request about this in the repository. Minigalaxy downloads games from GOG, both native Linux and Windows games.
- <interface-name>: joystick
I don’t know the explanation, but I was trying to run the game Oxenfree and it was giving me an error, but as soon as I connected the “steam-support” plug and tried to run the game again, it opened without any problems.
Hello @Kyuyrii
As already discussed about the joystick interface, we can not proceed with granting at the moment due to pending internal discussions.
Considering the steam-support interface request, given the snap functionality, I think it makes sense so +1 (#voteFor) from my side!
1 Like
I recorded a video to demonstrate the error I was having with the Minigalaxy, to show that the plug is really necessary, even when the UMU is not in use.
Hey folks!
-1 from me for granting minigalaxy any use of steam-support interface (#voteAgainst) for the same reason as for umu-run
Sorry for the inconvenience.
Like snapd-control or docker-support the steam-support interface gives a massive amount of permissions to an app using it … i.e. if you look at snapd-control it only gives full unmediated access to the snapd socket, meaning your snap would be able to fully control the host OS through it … if your app would just want to query a list of available snaps through it and nothing more, there is no snapd-query-apps interface or some such, so an app wanting to do this would have to get full access to everything, to prevent this until there are resources to implement a finer grained setup the policy simply forbids granting of snapd-control …
The steam-support interface is similar, it allows all things the steam snap requires including launching bubblewrap containers, additional access to graphics hardware that would normally not be possible and whatnot, it has literally only been developed for the steam snap … for your use-case we’d need something like a games-launcher interface that has only this specific functionality and does not open your app access to the world …
Until this is implemented I fear all these above interfaces will be limited to snaps that Canonical has fully control over to make sure nothing/nobody can abuse the extra permissions granted by it …
Feel free to submit a pull request to snapd for a finer grained games-launcher interface though, that might speed up the implementation …
The issue is that these game launchers, like Heroic Games Launcher, use UMU, which mimics the Steam environment. Therefore, the steam-support plugin is actually necessary for them.
Heroic, Minigalaxy, Bottles, Zordeer—all of these pose the same risk as Steam.
They all use the same tools as Steam, Wine/Proton. The danger lies only in what is executed: the .exe files from unknown sources. However, Steam also allows users to run them, so it doesn’t make sense to consider other launchers a risk if Steam is also a risk.
I’m not talking about allowing any random app to use the steam-support plugin. There are very few apps that actually need it, as very few apps use Wine/Proton/UMU.