Snaps & Ubuntu Core Desktop Talked Up At FOSDEM 2024

[user1]

Nah, I don't think distro packagers catch more bugs than other people. Problem in compiling process? Sure, but how the software is actually used, everyone has same chance to encounter a bug.

I'm not claiming packagers catch more bugs than users. When you get the software directly from the developer, then who will test it for bugs? only the user. On the other hand with traditional packaging not only the users test it, but also distro packagers. Remember Linus's law? "given enough eyeballs, all bugs are shallow".

And about downstream patches, there's a reason why a patch doesn't get merged. If you want to include those patches in your distro. Fine, you do you... Not really. There's just so many bug reports in upstream caused by downstream patches. Did I say so many? I mean fuckton of them, thousand of hours of developers time wasted just to find out that that bug a user reports, doesn't even exist in their software.

Honestly, this is the first time I'm hearing downstream patches may cause bugs that don't exist in upstream. And even if this is true you really seem to overblow the issue. Can you give at least some examples please? Personally, I know that if there's a bug in a package that doesn't exist upstream, it's most likely because the package is an older version.
Even in Debian, which probably has the most downstream patches in its packages (which some of them do get upstreamed eventually btw), it's not like most of them even cause a noticeable difference in the app behavior.

[Daktyl198]

I love how Canonical just has to double down on a double down on a double down. Years of wild ideas, and still the fundamental issues of snap aren't addressed at all, at best worked around with changes on the app.

I have bad news for you if you’re a fan of Flatpaks, buddy.

[TheJackiNonster]

I hate to spoil it for you, but the package maintainer can do the same. The package goes through a proper review only once, then you can make changes and don't have to ask.
I maintain applications both on Flathub and in a distro repository and I have to say that Flathub has been much more pushy about doing things right. They for example forced me to remove permission that became unnecessary when the app had already been on Flathub for 3 years. My packages in distro repos have never received so much scrutiny after they got in.

I made a different experience. On Flathub I never received any hint to lower permission requirements. Neither I did notice anyone checking my app for changes after initial verification. With snaps on the other hand my apps are continuously verified manually which I get notified about after a new build and they automatically notify me about outdated dependencies in my apps. Flathub doesn't seem to care at all about deprecated dependencies which is why a lot of apps probably contain known security issues inside.

That makes me prefer the way snap utilizes the .deb packages from the Ubuntu repository for most dependencies much more than runtimes and extensions for flatpaks. Because while developers might arrange custom runtimes and extensions to update their apps dependencies more easily, most people don't.

I've also made the experience with a flatpak from me, where I restricted the permission requirements to not be marked as "unsafe" on the Flathub page, that a user wasn't able to use it as intended anymore without manually adjusting permissions. The permission systems for both flatpaks and snaps are still horrible in my opinion because you either have to much access or too little - especially when it comes to filesystem access.

So from my point of view both systems are still extremely annoying and I still prefer native packages quite a lot, no matter the distro or implementation (.deb, .rpm or PKGBUILD).

[Sesivany]

I've looked at the sandbox permissions of a lot of Flathub apps and I have to say many of them are too lax. Like why in the world does LibreOffice and image viewers have full filesystem read/write access when it should at the very least be limited just to your home directory? Maybe the fact that your app has been 3 years on Flathub is most likely the reason why at some point someone scrutinised your app and asked you to remove unnecessary permissions.
There are now over 2400 apps on Flathub, which is a lot, so I think there's no way someone constantly sits and manually checks if every single app has proper permissions.

It's an automated test that every flatpak has to pass before the build. You can get an exception, but you have to request it and explain why the permission is needed.

[Artim]

During the last 1.5 years or so, I've heard such propaganda a lot from advocates of both Snaps and Flatpaks. You know, about all the benefits of getting the software directly from the developer and that repackaging it for different distros is a waste of time.

Recently, I've scrutinised the distro packaging process (previously I didn't know at all about how packages are made) and it made me appreciate traditional packages like never before. Particularly, I like the fact that packaging provides additional wall of security which you don't have if you get the software directly from the developer. What if the developer makes his software do something malicious and no one catches it before it gets to the user?
I also like the fact that at least some distros like Debian work closely with upstream. For example, Debian packagers may find bugs and report them to upstream. One thing I dislike about open source software in general is the over-reliance on users for reporting bugs. At least with distros like Debian, the packagers essentially also participate in bug reporting, not just the users. Again, something that's impossible if you get the software directly from the developer.

I doubt security in this context is the main benefit, but in another. Distributions - and especially Debian is known to do so - can enforce sensible best practices. E.g. they will force the app to have its configuration in /etc, not just some stupid location deep inside /var or /usr nobody usually checks. Also, they can force an app to put dependencies into packages (if there are any that aren't yet). The latter enables security patches by just patching the dependency. The first one isn't relevant with flatpaks, only with snaps, as Flatpak is pretty much useless on a server with mostly CLI usage. With snap and flatpak it's up to you if you include dependencies into your monolithic software.

But Flatpak does have one big advantage, security wise but also trust wise - snap does too, but to a lesser degree. Flatpaks are containerized, they can't access the system - e.g. not replace other programs, like MS (I think) was caught a few years back with their deb repo - and you can very easily manage permissions with Flatseal. E.g. WPS Office sometimes has best MS Office file support, yet I'd never let some shady chinese Office run wild on my system. With the Flatpak version, I just remove internet access and be done with it.

[Sesivany]

I made a different experience. On Flathub I never received any hint to lower permission requirements. Neither I did notice anyone checking my app for changes after initial verification. With snaps on the other hand my apps are continuously verified manually which I get notified about after a new build and they automatically notify me about outdated dependencies in my apps. Flathub doesn't seem to care at all about deprecated dependencies which is why a lot of apps probably contain known security issues inside.

Good for you that you never hit it. A manifest of every flatpak goes through a fairly thorough automated checks before every build and if the criteria is not met, the build is blocked. Also I do receive notifications about outdated dependencies or even pull requests from Flathub community.

[ssokolow]

I have bad news for you if you’re a fan of Flatpaks, buddy.

[citation needed]

[Artim]

I love how Canonical just has to double down on a double down on a double down. Years of wild ideas, and still the fundamental issues of snap aren't addressed at all, at best worked around with changes on the app.

To be fair, they have one point for them, snaps can be used on servers and there is the possibility of auto updates - although enforced. If Flatpaks would open up to services and what not, it might be a viable use case for some edge case software otherwise not available through repos (or maybe only through the likes of AUR, but who's insane enough to run Arch on a server). Right now you can only use snap, which is just bad. Also the containerization of Flatpak might be a good alternative to docker containers if you don't want to containerize everything but only a few apps.

[ssokolow]

I've also made the experience with a flatpak from me, where I restricted the permission requirements to not be marked as "unsafe" on the Flathub page, that a user wasn't able to use it as intended anymore without manually adjusting permissions. The permission systems for both flatpaks and snaps are still horrible in my opinion because you either have to much access or too little - especially when it comes to filesystem access.

"Manifest permissions" for the filesystem are considered a necessary evil for breaking the chicken-and-egg dilemma of growing an ecosystem and the plan is to treat them as deprecated and encourage packagers to not use them as more portals are developed for various niches currently unsatisfied, such as needing to access the sibling .bin/.ogg/whatever when you open a .cue or needing access to everything under ~/src/foo when you open ~/src/foo/foo.ide_project.

The network permissions are a single on/off toggle because they're still trying to find/advocate for a solution for doing it in a more granular way that doesn't require running flatpak run <appID> as root.

The "grant all under /dev" permission is a proxy for "we're still trying to work around libudev considering the API that, architecturally, must straddle the host/sandbox boundary (if we want working input device hotplug detection) to be internal and unstable. (Their plan to work around that is to make a USB device portal so libudev can be fully on the host side, and then add support for it to SDL and other gamepad-using things.)

Continued uptake of Pipewire will solve needing "grant all under /dev" for webcams.

etc. etc. etc.

TL;DR: Odds are, they don't like it either and are being held back by API limitations lower in the stack that they're still trying to negotiate solutions to.

[ssokolow]

To be fair, they have one point for them, snaps can be used on servers and there is the possibility of auto updates - although enforced. If Flatpaks would open up to services and what not, it might be a viable use case for some edge case software otherwise not available through repos (or maybe only through the likes of AUR, but who's insane enough to run Arch on a server). Right now you can only use snap, which is just bad. Also the containerization of Flatpak might be a good alternative to docker containers if you don't want to containerize everything but only a few apps.

1. You can use Flatpak for containerized non-desktop stuff... it's just not something they promote as a use-case they want to optimize for. (eg. Some CLI tools for flatpak package maintainers, such as org.freedesktop.appstream-glib are distributed through Flatpak... they just only show up in flatpak search, not the Flathub web UI.)
2. If you don't need containerization (i.e. If you want an equivalent to unconstrained snaps), that's what OSTree via something like rpm-ostree is for. Flatpak is OSTree plus containerization and XDG Portals.