Dedicated accounts, sandboxing, jails, Docker, and VMs exist.
The old thinking was that software was a user agent, serving the user's needs and interests. Some OSes (Debian comes to mind) explicitly acknowledge this.
Increasingly it's simply a naive and unjustified belief. Applications must be considered as untrusted necessary evils. Allocating them a minimum level of access is prudent.
Flatpak promises this, but fails to deliver.
Package managers offer this by convention, but rely on users (and security researchers) discovering and reporting malicious behaviour. Mitigation is retroactive: fixed behaviours or packages removed from the distro's repository, but the damage is done and existing deployments remain.
The underlying issue is one of packaging, updating, and distributing sandboxed apps.
And in recognising that packaging systems serve users, not developers.
It is not that simple [1], one need to earn trust. Distribution maintainers have much better record than browser addons authors.
Maybe we can trust big names, just like on Android — Google, Amazon. We may think that it is safer with paid software — they have something to loose. But free - I'd bet on maintainers.
If a library has a vulnerability, the distro often updates it and then every package that uses it has been patched. With these sandboxes things that include their own versions of dependencies, each one of them needs to be updated.
How is it any better than flatpaks having full access to your home directory? Yet, one of the points of criticism against flatpak is that it doesn't protect the users home directory.
Now, it's certainly debatable if flatpak could or should push more in that direction, like apple did when they introduced the sandbox for app store applications, but flatpak certainly does not have leverage to the same extend as apple has. So it's up to the app to opt in to a suitable sandbox set. It's a sad state of affairs, but I don't see a viable path for the flatpak folks to change that.
Package managers do not claim sandbox. No claim - no false claim - no accusation.
And it is easy to fix - publish capabilities in the gallery. Apple iOS "request location" shows that people care if they know. Sandbox certainly is a good thing. Without it Flatpak is just another package manager.
> One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment.
It’s better by not depending on yet another component or layer of abstraction. If you had a distribution which would use flatpaks for everything (ie no other packaging system involved), then sure, usual packages probably wouldn’t be any better than flatpaks.
But that’s not the point that is made against flatpaks - the point made in the article is “it allows access to the home directory, so it’s worse.”
Whether flatpaks is better or worse than packages depends on many other factors. Flatpaks allow software providers to package for multiple operating systems in one package, for example. This makes software available that otherwise wouldn’t be. Whether that’s worth it or not is debatable, but raising clearly invalid points to attack flatpaks is disingenuous.
Let’s count the various Linux flavors as different operating systems for this purpose, because they use wildly different package formats. And yes, I’ve installed software for fedora via flatpak that did not have packages for fedora at all or depended on versions of dependencies that the host system did not provide. (Specific python versions and dependencies IIRC)
Indeed. If you're an ISV packaging an application that uses OpenSSL, $DISTRO version N and $DISTRO version N+1 can easily be different OSes because they ship different incompatible OpenSSL versions, so what you do is provide a .deb/.rpm/.tar.gz that bundles a statically linked OpenSSL.
You don't understand how something running as root with full access to your entire filesystem is worse than something that has access to your home directory?
And they do? Just because they have some flaws doesn't mean that they're completely unusable. If you need an app that isn't on your distro but is on Flatpak, by all means use it.
> practically most packages on Ubuntu or Debian, for example, are outdated.
Some reasonable level of quality control does take time. There are distros that are much more up to date with upstream versions (Arch Linux, Gentoo, etc), but by living on the bleeding edge, you will eventually get cut.
You still need to distribute the static executables and there's no way to update them besides downloading them again unless the software has some auto-updater built-in. That definitely doesn't solve the issue.
I'm not sure I follow your reasoning here. If you are so concerned about the security of your system that you want to run each program on a sandbox, then you definitely do not want to allow programs to "update" themselves by automatically downloading random binaries from the internet.
Well, I never said I was concerned with security. I am to some extent but not to the point where I inspect every single update.
What I value most is having every software or library available through some form of package manager. Downloading static binaries off the internet without auto-update just doesn't make it which is why I like having Flatpak as a fallback.
It also makes it easier for the common user to have every piece of software available through one store. They don't need to know whether it's a .deb or a Flatpak underneath, it just needs to be there and work reasonably well.
There's really no other option: either distro maintainers include every single piece of software in the repositories (unlikely), or we need a common format that works on all distros (already the case with Flatpak).
What about packages that isn't provided by your distribution. Or packaged software in your distribution is too old, and you have a reason to use a new version.
Same, I remember I compiled a program like that 3 weeks ago, and it takes me half an hour to figure out how to do so. But I think expecting all the casual Linux to be able to do that is unrealistic. So I think it is necessary to have things like Flatpak, Snap, AppImages to exist.
BTW, I used to think that we can just provide a prebuilt binary to let user download from a website, but finding that isn't easy to achieve unless you use a language like Go, Rust... because I found that many C program are hard to compile with full static linking.
Absolutely the opposite of true. A tiny amount of the code on GitHub say is available in rpm/deb. Largely these package popular C and C++ code, and the majority of other stuff is not packaged. The language package managers are huge as well.
