|
|
Subscribe / Log in / New account

Fedora, GNOME Software, and snap

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

July 17, 2019

This article was contributed by Sean Kerner

A question about the future of package distribution is at the heart of a disagreement about the snap plugin for the GNOME Software application in Fedora. In a Fedora devel mailing list thread, Richard Hughes raised multiple issues about the plugin and the direction that he sees Canonical taking with snaps for Ubuntu. He plans to remove support for the plugin for GNOME Software in Fedora 31.

There are currently two major players for cross-distribution application bundles these days: snaps, which were developed by Canonical for Ubuntu and the Snap Store, and Flatpak, which was developed by Alexander Larsson of Red Hat as part of freedesktop.org. Both systems are available for multiple Linux distributions. They are meant to give an "app-like" experience, where users simply install an application, which comes with any dependencies it has that are not provided by the snap or Flatpak runtime.

The GNOME Software application has a snap plugin that, when enabled, supports the distribution, installation, and management of snaps. The Fedora project currently provides the snap plugin as a package in Fedora 30, though it is not installed by default. Hughes is the Fedora maintainer for the plugin; he announced his intention to disable the plugin since, he says, he was told that Canonical was not going to be installing GNOME Software in the next Ubuntu Long Term Support (LTS) release.

Recently Canonical decided that they are not going to be installing gnome-software in the next LTS, preferring instead to ship a "Snap Store by Canonical" rather than GNOME Software. The new Snap store will obviously not support Flatpaks (or packages, or even firmware updates for that matter). The developers currently assigned to work on gnome-software have been reassigned to work on Snap Store, and I'm not confident they'll be able to keep both the old and new codebases in the air at the same time.

Hughes is also concerned about the stability of the snap plugin, noting that "the existing snap plugin is not very well tested and I don't want to be the one responsible when it breaks". Additionally, Hughes outlined a few other areas of concern that have led him to plan to drop support for the snap plugin in Fedora.

At the moment enabling the snap plugin causes the general UX [user experience] of gnome-software to degrade, as all search queries are also routed through snapd rather than being handled in the same process. The design of snapd also means that packages just get updated behind gnome-software's back, and so it's very hard to do anything useful in the UI, or to make things like metered data work correctly. There's also still no sandboxing support years after it was promised, which means on Fedora running a snap is no more secure than "wget -O - URL | bash", again much unlike Flatpak.

The other issue that Hughes raised is that in his view, enabling the snap plugin would also enable the Snap Store, which would be a violation of Fedora rules for enabling access to non-free software (the same is true of enabling Flathub support, he said). He noted that he expects that the decision will be controversial and that there will be those that want it turned back on in GNOME Software. He suggested a path forward if there were developers interested in maintaining snap support for GNOME Software:

My answer there would be that I'm perfectly happy with someone creating a new gnome-software-snap top-level package (plugins in gnome-software are just runtime loaded .so objects, rather than all compiled together) and then they're responsible for keeping it up to date with any plugin ABI breaks in gnome-software upstream (usually once per GNOME cycle) and for any API or behaviour changes in snapd-glib. Basically, as long as it's not my email that gets pinged by bugzilla when it breaks it's fine.

In a blog post, Hughes provided his views on the situation and the bigger picture. The post was of the form of an extended automotive analogy that took issue with companies that are not working toward enabling an open ecosystem supported and used by multiple parties. Overall, it was a thinly veiled swipe at Canonical.

Among those that disagreed with the decision was Fedora contributor Neal Gompa who disputed many of Hughes's assertions, including the claim that snaps are not sandboxed.

This actually hasn't been true for almost a year (snapd has seccomp and other filters in place), and in the last few months, we've rolled out *very basic* SELinux support into snapd. Today, snaps are sandboxed through the snapd-selinux policy, which generally confines snaps to only interacting with each other, and select holes for system integration.

We've been working very hard upstream on improving this story for Fedora, and we've made tremendous progress.

Canonical responds

At the core of the issue of whether Fedora will or won't ship the snap plugin is whether or not Ubuntu will be moving away from GNOME Software and just use its own Snap Store by default for the next Ubuntu LTS release. It's a question that Canonical has not definitively answered, though it has stated that it plans to keep supporting the snap plugin for GNOME Software.

LWN contacted Canonical to ask about Hughes's claims. In an email, Will Cooke, desktop engineering director at Canonical, said that in the last week there have been several discussions at the company about the Snap Store. "To date, there has been no decision on this potential change, nor have any announcements been made to this effect," he said. "We remain committed to maintaining snap support in GNOME Software and ensuring users who wish to use snaps can do so regardless of their Linux distribution."

In the mailing list thread, Canonical developer Robert Ancell emphasized that Canonical is committed to maintaining the GNOME Software snap plugin. He also extended an offer of support to help Fedora include the snap-plugin in a way that is stable. "We're happy for the snap plugin to be built in a separate source package for Fedora if that's necessary and we're obviously keen to see snapd-glib up to date in Fedora", Ancell wrote. "The dependencies are fairly light so it should be quick to update but let us know if there is anything we can do to make this easier."

Gompa responded, wondering how the situation had deteriorated to the point where the plugin was seen by Hughes as being unstable. Rather than building a Fedora-specific source package, Gompa would prefer everything to be done upstream, and is hopeful for more communication to help identify any issues.

I'd *really* prefer to find a solution which lets us keep building the plugin as part of the gnome-software source package. If there have been snap plugin specific issues, I haven't heard of them, and I *know* that Robert and the rest of the folks working on non-Ubuntu snap work would like to know about them, so they can do something about it. Sadly, omniscience and mind reading technology don't exist, so we need to be told these things. :)

Flatpak vs. snap

Red Hat is a big supporter of Flatpak. The Fedora Silverblue distribution is designed with Flatpak as a core component, for example. In an interview with LWN, Fedora Project Leader Matthew Miller said that, in his view, Flatpak and snap can both happily coexist. "Obviously Red Hat's desktop team is heavily invested in Flatpak, and we also have members of the Fedora community who are very interested in snaps — and I include Canonical employees working on snap in that," he said.

Of concern to Miller is the source of snaps and in making sure that there are multiple developers and organizations that are producing snaps that are available via GNOME Software. Miller noted that the Fedora project is not just a producer of a base operating system, or just a desktop without apps, it also has a long history of contributors working on packaging end-user applications. "We have a project where Flatpaks in Fedora are actually automatically generated from our existing packages, and some Fedora developers are working on a plan for doing a similar thing with Snaps," Miller said. "We have a talk on that at our upcoming Flock conference and I'm looking forward to learning more."

Decision time

From a governance perspective, Miller explained that Fedora has a defined change process and it's ideally used for anything with a large impact. In Hughes's view, the snap plugin change would only have limited impact. Hughes said that the snap plugin was never shipped for Red Hat Enterprise Linux (RHEL) and it's not a feature that is installed by default for Fedora. The change would only impact a small number of people, he said, so it may not need a full-on change proposal. Fedora program manager Ben Cotton said that while a change proposal would be nice, it probably isn't needed; adding something to the Fedora 31 release notes should do.

Decisions on minor changes can be handled by Fedora maintainers. Miller noted that if Hughes feels like he can't reasonably maintain a feature, that's a judgement call. "Ultimately we do put a lot of trust in our maintainers, and I personally have a lot of trust for Richard here," Miller said. But Miller noted that currently it sounds like there is community interest in preserving the snap plugin and he thinks it's likely that someone will step up to do that. "This is still a developing conversation," he said.

From a user perspective, however, even if Fedora 31 disabled the snap plugin in GNOME Software, users could still download GNOME Software directly from upstream, which still has the plugin."Either the functionality will have a strong owner and support, in which case there will be no problem in Fedora, or else it'll become clear that it's not maintained in which case it will be dropped upstream as well," Miller explained.

The discussion is likely to continue for a while longer as different developers and community members make their voices heard on the topic. Fedora 31 is currently scheduled for release in October, with a beta freeze set for August, so there is still plenty of time for a final decision to be made.

Index entries for this article
GuestArticlesKerner, Sean


(Log in to post comments)

Fedora, GNOME Software, and snap

Posted Jul 17, 2019 21:13 UTC (Wed) by halla (subscriber, #14185) [Link]

"There are currently two major players for cross-distribution application bundles these days: snaps, which were developed by Canonical for Ubuntu and the Snap Store, and Flatpak, which was developed by Alexander Larsson of Red Hat as part of freedesktop.org."

No. There are three. What the author might have meant is "there are two corporate-backed players..." -- which to some minds translates to "important", but for me, as the maintainer of a widely used application, snap is okay but not actively awesome, flatpak sucks because of the attitude of its maintainers towards freedesktop.org standards, and appimage is what works best for my users.

Fedora, GNOME Software, and snap

Posted Jul 17, 2019 21:29 UTC (Wed) by SMK (guest, #131799) [Link]

Yeah you're right (of course). I should've had Appimage listed too. Which remind me, I need to spend *more* time trying out Appimage overall...

Fedora, GNOME Software, and snap

Posted Jul 17, 2019 21:48 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

>flatpak sucks because of the attitude of its maintainers towards freedesktop.org standards

What standards?

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 5:18 UTC (Thu) by davidstrauss (guest, #85867) [Link]

I wouldn't call them standards as much as the interfaces and daemons (e.g. D-Bus) that Flatpak provides to allow sandboxed apps to access resources outside the sandbox. I'm not sure what alternative there is, though, other than not sandboxing. A sandbox without such facilities isn't very useful, and there aren't more popular/standardized approaches to solving the problem on Linux desktops. Android has intents for a similar reason, and those are also homegrown (and not very portable to Flatpak's environment).

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 6:39 UTC (Thu) by halla (subscriber, #14185) [Link]

I was thinking of https://github.com/flatpak/flatpak/pull/2696 -- I checked the spec, and no, I don't see anywhere anything like what is claimed there, that icons > 512x512 are forbidden by the icon theme spec.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 10:11 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Looks like a minor disagreement. Claiming that Flatpak sucks and doesn't support freedesktop.org "standards" because of it seems like a disproportionate reaction for something that can be discussed quickly over IRC, no?

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 11:17 UTC (Thu) by DigitalBrains (subscriber, #60188) [Link]

The claim made in that PR is
Putting larger icons there is not going to make desktops pick them up, if they follow the icon theme spec.
The icon theme spec says that the icon theme description file lists all the subdirectories of the theme. "For every subdirectory there must be a section in the index.theme file describing that directory". If you now take the latest version of hi-color's index.theme, this does not list a directory for 1024×1024 icons. Even the scalables top out at MaxSize=512 or smaller. So the claim seems substantiated: if an implementation follows the icon theme spec by taking index.theme as the leading source of available directories, they will not notice a 1024x1024 directory. In fact, even creating that directory violates the spec as it says that "for every subdirectory there must be a section in the index.theme file describing that directory".

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 11:36 UTC (Thu) by halla (subscriber, #14185) [Link]

Sorry, I don't buy that. The icon theme spec (https://specifications.freedesktop.org/icon-theme-spec/ic...) isn't the same as the hi-color icon theme: there can be other themes that follow the spec and have other sizes. The index.theme file is code, not spec.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 11:44 UTC (Thu) by rsidd (subscriber, #2582) [Link]

The WONTFIX attitude is common to GNOME and related projects. But, just out of curiosity, why a 1024x1024 icon? The highest-resolution monitor available today seems to be 7680×4320 and a 1024x1024 icon will fill a quarter of its height and an eighth of its length. That monitor approaches the resolution of the human eye, so I don't see larger resolutions on the way. And every monitor I've ever seen is much more low-res than that.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 11:58 UTC (Thu) by halla (subscriber, #14185) [Link]

Well, that was an argument made shortly before this check appeared in the flatpak build process in a blog on planet.gnome.org by a designer. And I guess there's something to it, but we need to have to have 1024x1024 icons anyway to conform to Apple's standards for retina screens.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 14:47 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

Any Apple requirements are irrelevant for *Linux* sandboxing solutions.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 19:55 UTC (Thu) by halla (subscriber, #14185) [Link]

Gee, thanks for telling me that!

But anyway, anything that forces me, unnecessarily and uselessly, to make a change, a difference per OS is lumber, and in this case, something we had been installing for more than a decade on Linux suddenly was, without any good reason, rejected. I did not like that, and I did not like not getting an answer to my question, and I did not like having to spend time on that bug report.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 11:53 UTC (Thu) by DigitalBrains (subscriber, #60188) [Link]

I'm trying to understand. Are you saying that the claim from the PR
The biggest icon size supported by the hicolor theme definition is 512x512. Putting larger icons there is not going to make desktops pick them up, if they follow the icon theme spec.
might be correct but is irrelevant? Because I think I showed it is correct. You're saying that you want to build large icons for themes that do support it or for people modifying the hicolor theme to include these larger icons?

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 19:57 UTC (Thu) by halla (subscriber, #14185) [Link]

What I mean is the icon theme spec, which is what I care about, does not make such a limitation. This particular icon theme does not define larger sizes, though it could, because it is allowed by the spec, the spec allows any size of icon.

Fedora, GNOME Software, and snap

Posted Jul 20, 2019 0:17 UTC (Sat) by flussence (subscriber, #85566) [Link]

>No. There are three. What the author might have meant is "there are two corporate-backed players..."

There are four. These three irrelevant perpetually-infighting ones, and the app store everyone uses: Steam, which is a trash fire with no sandboxing.

Fedora, GNOME Software, and snap

Posted Jul 20, 2019 11:49 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

> These three irrelevant perpetually-infighting ones, and the app store everyone uses: Steam

Feel free to provide the evidence that backs this claim. Clearly, not everyone uses steam but can you show that the atleast the majority does?

Fedora, GNOME Software, and snap

Posted Jul 20, 2019 21:37 UTC (Sat) by flussence (subscriber, #85566) [Link]

I could, but it wouldn't make a dent in the RedHat-Canonical format war, and I don't really care to see either side win.

Fedora, GNOME Software, and snap

Posted Jul 21, 2019 10:29 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

> I could, but it wouldn't make a dent in the RedHat-Canonical format war, and I don't really care to see either side win.

What does showing basic evidence of your claims have to do with any supposed war?

Fedora, GNOME Software, and snap

Posted Jul 21, 2019 20:44 UTC (Sun) by flussence (subscriber, #85566) [Link]

Immediately sealioning anyone who points out the emperor has no clothes is not a good look.

Instead of racing to become the first distro to reinvent 0install packages 2 decades late, take note of what people are actually using computers for, and why that idea was ignored back then.

You refuse to see the wood for the trees.

Fedora, GNOME Software, and snap

Posted Jul 21, 2019 22:17 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

None of this looks this evidence. The claim appears unfounded

Fedora, GNOME Software, and snap

Posted Jul 21, 2019 17:56 UTC (Sun) by ThinkRob (guest, #64513) [Link]

Isn't Steam kinda tackling a different problem though? Specifically, it's trying to solve the "I want to sell my proprietary software to Linux users without going insane re: distribution + packaging" problem.

Ignoring, for a moment, the various debates about FOSS v. proprietary, it doesn't seem like Steam's really trying to solve the same thing as snap et al. And it *does* seem to work for what it's trying to do -- letting people sell to Linux users... doesn't it? (Pardon my ignorance of its success/failure -- I don't use it, and never have/will... but it seems like it's popular!)

Fedora, GNOME Software, and snap

Posted Jul 21, 2019 20:28 UTC (Sun) by pizza (subscriber, #46) [Link]

I've always felt that "Selling proprietary software to [Ubuntu] Linux users without going insane" is the ultimate point of snap as well.

Fedora, GNOME Software, and snap

Posted Jul 22, 2019 22:31 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

Specifically, it's trying to solve the "I want to sell my proprietary software to Linux users without going insane re: distribution + packaging" problem.

But if you ignore the "sell proprietary software" part, it still has to deal with the "without going insane re: distribution + packaging" part of the problem. The basic point is a reasonable one: Steam seems to have come up with a reasonable solution that allows game makers to solve the main problem snap and flatpack are trying to solve.

Fedora, GNOME Software, and snap

Posted Jul 22, 2019 22:48 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

>The basic point is a reasonable one: Steam seems to have come up with a reasonable solution that allows game makers to solve the main problem snap and flatpack are trying to solve.

Sure but Steam is not a general purpose solution to the problem. Non-games are not widely using it as a distribution platform. There is no smaller runtimes, no sandboxing, no portals, no confinement etc that makes it useful for that reason

Fedora, GNOME Software, and snap

Posted Jul 24, 2019 20:34 UTC (Wed) by ThinkRob (guest, #64513) [Link]

That was my understanding as well from reading about it -- that it handled distribution, but not really packaging per se, and certainly not isolation. I didn't say that in the first post because I don't use Steam and wasn't sure if things had changed since I first learned about it...

That said, I can't see why Steam couldn't adopt snap or whatever once they mature somewhat. Or does Steam target systems too old for container tech?

Fedora, GNOME Software, and snap

Posted Jul 24, 2019 20:56 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> That said, I can't see why Steam couldn't adopt snap or whatever once they mature somewhat. Or does Steam target systems too old for container tech?

Right now, the official snap store is proprietary and there is no community store that is not tied to Canonical. Snaps are also not as mature outside of Ubuntu. In theory, all of this is fixable and either snap or flatpak could be adopted by Steam

Fedora, GNOME Software, and snap

Posted Aug 15, 2019 17:16 UTC (Thu) by oak (guest, #2786) [Link]

Steam is used for games, games need 3D drivers, those need to be updated more frequently than Steam and each GPU family needs its own driver. Whereas Valve’s library bundle is very old.

I.e. It’s not a good candidate for containers, as drivers need to come from the distro.

Another problem is when 3D driver has incompatible C++ dependency compared to what game otherwise depends on...

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 5:01 UTC (Thu) by abo (subscriber, #77288) [Link]

I want to agree, but this reasoning falls flat because GNOME Software is not actually stable even without the snap plugin.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 10:00 UTC (Thu) by swilmet (subscriber, #98424) [Link]

I totally agree, I've always had lots of bugs with gnome-software.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 6:05 UTC (Thu) by davidstrauss (guest, #85867) [Link]

> [That snaps are not sandboxed] actually hasn't been true for almost a year (snapd has seccomp and other filters in place), and in the last few months, we've rolled out *very basic* SELinux support into snapd.

I disagree that seccomp filtering qualifies as sandboxing, at least for desktop applications. Filters like seccomp are mostly useful for preventing unprivileged code execution from achieving full privilege escalation, as it allows filtering out uncommon and unused system calls that might be useful to an attacker exploiting a kernel vulnerability. It is not terribly useful for sandboxing for desktop applications because escalation to root isn't the prize. The prize is the content in your home directory and other data accessible by your unprivileged (but local) user: SSH keys, other private keys, and PII. It is not sandboxing when the payload for attackers is also in the (supposed) sandbox.

Not only is seccomp filtering weak against the threat model for desktop applications, it also represents no progress toward meaningful sandboxing that *does* require application changes, like replacing traditional expectations around arbitrary $HOME and webcam access with more restrictive mechanisms. Most seccomp filter lists (of the sort used in Snaps, Docker, etc.) are designed to be only as tight as they can be without making anyone change anything. "Sandbox" typically implies something small and well-contained, but this sandbox is constructed by dumping sand anywhere people happen to be going already or might be expected to go.

As for using Snap for server applications, I don't see much value over existing container or virtualization technologies. Many of them have more meaningful and mature sandboxing and developer ecosystems than Snap's.

Fedora, GNOME Software, and snap

Posted Jul 19, 2019 3:54 UTC (Fri) by gdt (subscriber, #6284) [Link]

For the ordinary user the ability of an application to encrypt their ~/Pictures directory is devastating. Flatpak, Snap, AppImage, etc are an opportunity to add more meaningful access control to applications. It's a shame that this opportunity wasn't taken.

Fedora, GNOME Software, and snap

Posted Jul 19, 2019 5:11 UTC (Fri) by abo (subscriber, #77288) [Link]

The Flatpak sandbox can certainly prevent access to the user's files. Some applications do request access to all of the home directory, but that should be phased out and replaced by use the "portal" system.

Fedora, GNOME Software, and snap

Posted Jul 18, 2019 14:04 UTC (Thu) by Freeaqingme (guest, #103259) [Link]

Personally, I don't like the snap packaging at all. I understand its use for proprietary software distributed by third-parties. However, Canonical is now also shipping regular software as snaps (gnome-calculator, anyone?). The sandboxing that it attempts to do results in hard to troubleshoot issues, especially if there's anything different than what ubuntu expects (like, uhm, have a custom $PATH variable with a path that's not included in the sandbox).

I'm fairly certain Debian will stick to the .deb packaging for the next 100+ years, so when my ryzen 3000 system arrives this weekend I'll just see how Debian performs on a desktop. So long - from an Ubuntu user of 14 years.

Fedora, GNOME Software, and snap

Posted Jul 20, 2019 12:10 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

Debian has been working quite nicely on my desktop for several years :)


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds