Umu-support refused

snapd
1

The link above is the pull request I opened in the Snapd repository.

This pull request was to create the umu-support interface, which would allow apps like Heroic Games Launcher, Rare, UMU, and Zordeer to function correctly on Snapd.

This would make life easier for users and developers, as it’s simpler and safer to work with Snapd than with .deb packages.

The pull request was rejected, and security isn’t a good justification thanks to the existence of Steam Snap.

Users have wanted access to these types of apps on the Snap Store for years, many years, and the opportunity we had to change that was wasted.

If these types of apps can’t exist on the Snap Store today, then they couldn’t have existed before either; all the effort of the packagers/developers would have been useless.

It’s not the game launcher developers who are against Snapd, it’s Snapd that’s against the game launchers.

This is a rant; as a user, I’m frustrated. Since 2018, they’ve been trying to add game launchers to the Snap Store, back when it was Ubuntu 18.04, and now we’re on Ubuntu 26.04.

I imagine it must be annoying to see someone questioning how things are done, questioning security concerns, but the way things are currently, we’re not progressing, we’re just getting stuck.

2

In my opinion, fixing this issue and cleaning up unmaintained apps from the app store, including some by starred users, should be the ultimate priority for Snap for desktop at the moment. I don’t want to be repetitive about this since it’s counterproductive, and after all, it’s a service I’m not paying for.

1 Like
3

Thanks for continuing to engage with us on this. I’m the director of the snapd team, and I closed the PR you raised.

We’ve discussed this numerous times in the snapd team over the last months: I can assure you that we do care about finding a solution that works. I should say: it’s not just a snapd question - gaming support rests with the Ubuntu Desktop team. So this is an ecosystem level question.

I think your PR was certainly helpful in that it looked at whether we could find an appropriate technical approach given the current limitations. Ultimately, the Canonical security engineering team did not give us the go ahead with this.

We do have some legacy commitments here - you rightly point to Steam as an example - but that doesn’t necessarily represent a useful precedent in passing a security review.

One of our challenges is that in the current solution, we have a fairly binary choice between classic/strict confinement. We have an understood process to request classic confinement - in this case the security team will look to vet publishers. For example, what is the user base? the health of the maintainer community? how are security issues handled?

The engineering bandwidth issue is that we can’t define a individual specialized interface for every publisher: that doesn’t scale.

Where the blast radius is contained, for example when it only applies to a particular embedded product, it is somewhat easier to pass security review. But here we’re talking about the general desktop use case, which has a considerably more complicated set of threats.

“Sub-apps” also introduce additional complexities, both technical and policy. However, we have several reasons to improve the technical approach around “sub-sandboxes”: this is not just about games launchers, but also for sandboxing containers and LLMs. I can’t promise a date yet, but it’s actively being worked on.

5 Likes
4

I mentioned Steam, but UMU doesn’t need all the permissions that Steam has.

The point is that UMU mimics some of what Steam does, so certain permissions are similar.

Without umu-support, game launchers don’t work correctly; without game launchers working correctly, game launcher developers can’t test them on Snapd, which causes game launcher developers to move away from Snapd.

Making game launcher developers move away from Snapd also makes users move away from Snapd.

In my pull request I mentioned 4 Snap packages; trusting 4 Snap packages, with 3 of them being very well-known projects, isn’t absurd.

Or, at least, trusting the Heroic Games launcher; if it could at least use umu-support, it would make a big difference.

5

I know I’m being repetitive.

But it’s necessary.

What UMU does is follow what Valve did; Proton needs a specific environment to function correctly, and UMU is what makes Proton work correctly outside of Steam.

UMU isn’t just any project; it’s not something the community created without reason. It’s not equivalent to Lutris, Bottles, Heroic, or anything like that.

UMU is used by several launchers; it’s essential for Proton to function. A Snapd interface for UMU to work isn’t the same as, for example, creating a Snapd interface for Lutris to run apps from outside the sandbox. I’m not trying to create a precedent for lutris-support, heroic-support, bottles-support, or anything like that.

Zordeer was created considering the limitations of Snapd, avoiding dependence on anything outside the sandbox. It can run games using Wine or Proton; it wouldn’t need its own interface to function, only the umu-support interface because UMU is necessary to use Proton.

That’s what I’m trying to say: we just need UMU to work. If it works, the other launchers (that don’t need to break the sandbox) will also work.

6

Lutris would need to break the sandbox to function, so a Snap version of Lutris wouldn’t work. The Snap version of Bottles was abandoned, the Snap version of Heroic was abandoned, the Snap version of Rare exists because I packaged it, the Faugus developer doesn’t want a Snap version…

The developers of large, important, famous launchers, none of them have the patience to discuss Snapd again and again, only for nothing to change in the end.

I know there’s bureaucracy, but taking so many years for no progress to happen makes it seem like nobody cares about this situation.

The solution is very simple: umu-support. It may not seem ideal, but steam-support wasn’t either.

Just as the home and removable-media interfaces aren’t ideal, removable-media gives access to everything in /media, /mnt, and /run/media, but it’s better than apps not being able to do what the user needs/wants.

7

Hello again! Apologies for the slight delay in getting back to you, it’s been a busy week. I also saw the discussion on our matrix channel.

I wanted to answer your point from matrix “if the security model is preventing UMU from working on Snapd, but not preventing Steam from working on Snapd, then this security model isn’t being followed; it’s a flimsy excuse.”

I absolutely agree with you, by the way: if we make something that’s super secure, but nobody uses it, that’s a tragedy. We want to bring free software to the widest audience. However, there’s a competing pressure - we can lose that audience if we don’t protect them from CVE vulnerabilities and crypto thieves, etc.

It’s important to recognise that the security model isn’t just the technical measures in snapd to provide the sandbox. It also encompasses policy questions, human and automated review, supply chain threats, publishing vetting, the ability of our organisations to keep delivering updates for 15 years.

We’re working on all of these things. As you probably understand, we focus on areas where our efforts build revenue that can fund more efforts.

On the feature to allow a snap to create additional sandboxes: it’s in active design, although we’re a while away from having a proof of concept. The sandboxing itself is well understood: our challenge is to add to our conceptual framework the ability to have multiple sandboxes per snap (instead of the snap and the sandbox being one and the same). This will continue to be a focus through the 28.04 LTS cycle because it also helps improve the way we support K8s.

3 Likes
8

Thank you very much for reading my comments and responding, but I need to ask you to read this as well.

The main problem with this discussion is that the supposed problems with umu-support not being specifically mentioned, making it impossible to understand what the consequences would be, especially for a regular user.

Furthermore, if umu-support is considered dangerous, it’s implied that steam-support is also dangerous, but if steam-support is dangerous, it means that Canonical is neglecting user security so that Steam can function on Snapd.

In other words, the situation can be viewed in two very bad ways:

1 - Canonical is putting user security at risk with steam-support and doesn’t care.

2 - Canonical somehow trusts Steam, a proprietary software, but doesn’t trust UMU, an open-source software, meaning it doesn’t trust the community developers.

I know it may seem like I’m jumping to conclusions and being quite negative, but these are actually conclusions that users and other developers may have, due to the lack of communication, explanations, and because we’ve been almost a decade without these launchers working on Snapd.

When these game launchers finally work on Snapd, several years from now, Snapd’s reputation will be even worse, and the developers of these launchers may not even be interested in publishing them on the Snap Store.

We can publish apps that aren’t developed by us, but this burdens people, and some necessary code changes may not happen.

My discussions aren’t just because I want game launchers to work on Snapd; I want the opinion of users and developers about Snapd to improve, because currently many developers don’t care about Snapd, and some even see Snapd as a problem.

I publish several emulators, and they were relatively simple to get working on Snapd. The developers of these emulators could have published them on the Snap Store, but they didn’t want to, and that’s not by chance.