Flatpak – An Insecurity Nightmare (2023)

Everyone else is getting off dbus, is working to let the compositor have power, have authority. Dbus is this other system that has some security options but that rarely is well locked down.

And it's just wild to me that there's such ongoing protest against using Wayland protocol development that's so insistent, and it's especially annoying and frustrating seeing it from biased folk like Flatpak who want to make sure there is no discrete source of authority, who want to make sure they can own a chunk of the UX. DBus and their protocols make sure Wayland doesn't become the one way to run a good desktop, that you have to keep having multiple totally different messaging systems going. Fine, I don't begrudge you that as an option, but don't keep road blocking those who want to develop Wayland, please!

KDE and GNOME in the 2000's already had everything in place, for vertical application development, frameworks and co, the only part missing was having OEM support for selling ready made systems, instead of reverse engineering hardware all the time.

Instead rebooting the experience, incompatible Gtk+ versions, multiple sound systems, a X Windows replacement that is yet to be widely available,....

Eventually the peace of mind is to use it the headless, time sharing approach that UNIX was developed for, and leave it at it, ssh and Web instead of telnet and X Windows of yore, into servers where OEMs actually care to support their hardware.

The sandboxing would be an easier sell if it allowed interconnections between apps as appropriate. Yes, I do want KeepassXC to be exposed to the KeepassXC extension in Firefox. Yes, I do want yabridge to expose VST instruments to BitWig. We don't want to be hardcoding support for individual pairs of apps either, so the mechanism would have to be generic.

Abstracting away filesystems also only goes so far. Running Filelight sandboxed for instance is just too slow to be useful.

And the distribution would be an easier sell if it allowed for standalone app downloads without going through a centralized hub with dedicated download tools.

Hopefully these are things we'll eventually see solved. Until then, it's still pretty damn good to be able to install many common apps regardless of distro specifics. An easy thing to take for granted, that. Used to be the answer to installation woes was "what's so hard about tracking down every dev dependency and compiling it yourself?" and it's nice that we're firmly moving on from that.

Running up-to-date desktop apps like synology-drive, prusa slicer, keepassxc, kdenlive or even Steam at the same time without any conflicting dependencies and configurations tainting the distribution. And if you do not want to use it any more, you can simply remove it with little or even no traces left behind. I love the experience to get these -- including updates -- from within discover (KDE) or gnome-software.

And don't mix flatpak with snap. Different technology, I share mixed feelings about snaps.

You know, I think I prefer it this way. Things that go mainstream tend to attract the kind of people who think they can improve a product by removing most of the features that made it powerful to begin with. They'll say that simplifying the UX by way of reducing the number of choices the user can make will ease user confusion and make the app easier to maintain as a side benefit. And don't forget, you have to chase the latest UI aesthetic trends coming from big players like Apple, Google, and Microsoft if you want people to think you're still relevant.

I love using Linux on the desktop and dearly hope it never, ever goes mainstream.

Linux, Unix and most computers were designed from the ground up as open system where everything can access everything.

It’s absolutely not secure, but that’s not what flatpak is supposed to fix.

Flatpak is supposed to make installations of apps easier by sharing common dependencies across all distributions. That’s all. And in a way, it works.

It has downside even on that, people who have slow internet connection will require hours to download a simple calculator app whereas it took a few seconds before, but it works.

Now on the sandboxing part, you can’t fix a sinking ship with a chewing gum in the hole. The whole structure is not designed to work this way.

It has to come from yet another distribution where permission are enforced at the operating system level, like on macOS. It’s a lot of work, and then you got to get developers on board, so it will never happen and it’s fine. Linux is not macOS, it doesn’t have a trillion dollar company backing it up and it’s not unified.

You got to play with your strength, not your weaknesses.

- small utility 100kB

- libraries needed to sandbox small utility 1GB

I just $##@#$@&$¡! And I searched more for *.deb package

The only case where I do find Flatpak useful is to install proprietary electron based applications that do not interact with the rest of the system so much, but I try my best to avoid using those in the first place.

If one's use case for a tool (e.g. QGIS) requires extensions that sit outside of how the flatpak was composed, well, sorry.

I have about 30 years of experience with running Linux. Rarely as my main system (though I did use this particular laptop for a few months in between two macs at some point).

I got rid of both snap and flatpak. I like the idea of those two. But they are just too much of a PITA to deal with. I'd like this stuff to work how it works on my mac: mount .app image, drag the app to the Applications folder and done. On Manjaro, if I want something, I just 'yay <package>' it.

I find it very telling how commercial application developers that actually do explicitly support Linux advertise their Linux support on their websites. Mostly it does not involve the words flatpak or snap. Just not a thing. Generally you'll find some link to a deb, rpm, or tar ball (in that order). And good luck with that. Yay does a fairly good job of converting deb files for use with arch based systems. It's how I installed Chat GPT Desktop on this thing before traveling, for example.

Basically the status quo for commercial application developers targeting Linux is to: 1) ignore distros repackaging other people's software 2) ignore niche package management solutions 3) just cover the basics which is Ubuntu (deb) first and then everything else. Which means you get a deb file, maybe an rpm, and not much else typically. What they typically don't do is work with half dozen app stores, distribution specific repositories, package managers, and other walled gardens to bend over backwards to distribute their software. None of them are large enough to be worth the overhead.

This system kind of works. There's no need for OpenAI to support Manjaro with a Manjaro specific package. Yay can work with a simple deb. All the developers have to do is make sure to statically link the essentials and not make too many distribution specific assumptions.

The author forgot Windows Vista which started this whole shitshow of granular permission popups ;)

But am I the only one who fundamentally does not want this permission popup crap on a desktop operating system? I explicitly want applications to access the data of other applications or even remote-control other apps, that's the base for building automated workflows where the result is more than the sum of its parts.

Let me define sandbox boundaries for whole groups of applications and special safe locations for actually sensitive data, not require each application to live in its own isolated sandbox.

This article is too wordy and too rambling. The resolution is there.