I agree with all of this and... I just don't care.
I download a Flatpak from the Pop OS store and it works. It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb!
I've never got into dependency hell where I need to apt-get a specific version of a library from a dodgy PPA.
If I uninstall it, Flatpak doesn't leave acres of cruft strewn around my disk.
I don't see how randomly installing a Flatpak is any worse for security than compiling the source myself. The permission model on Linux is far worse than Android - so I just hope for the best anyway.
Snaps never worked right for me - and seemed to frequently break. But all my Flatpaks have run fine and at full speed.
Does it take up more disk space? Sure. But that's a trade-off I'm willing to make in order to just download and run with no extra work.
Sure, there are some efficiency and security gains to be made. But I'm much happier with a Flatpak world than the alternative.
Pretty sure you can by doing "dpkg --root=$HOME -i mypackage.deb" or something like that, long time ago I used dpkg, but it should be possible with some flag.
Otherwise I agree, Flatpak is a breath of fresh air!
This often doesn't really work in practice on its own at least, since packages tend to hardcode their in installation directories. (You could try using an overlayfs, but at that point it's becoming pretty cumbersome.)
You can recompile package from source to support installation into `~/.local` (see `man 7 file-hierarchy`), but burden to support this will be on you, including updates, protection from malware and viruses, firewalling, and so on.
For example, rust's cargo can compile and install applications into `~/.local`, but it's pain to keep them up to date, so I prefer to use same tools from my OS (Fedora) distribution repo instead.
--root=dir
Set the root directory to directory, which sets the
installation directory to «dir» and the administrative
directory to «dir/usr/local/var/lib/dpkg».
Is there a point you're trying to make, or are you asking for technical information which would be better answered by man dpkg or a quick Internet search?
I am not trying to make any point, I am genuinely curious where dpkg is going to put those files since its the first time I read you can dot `dpkg --root=$HOME -i mypackage.deb`.
For instance I always do `python3 -m pip install --user wormhole` or `pip install --user wormhole` instead of sudoing my way to permissions hell. Python apps get installed in $HOME/.local/bin, so no cruft for other users.
But stuff installed with deb packages often have hard coded pathways and assumptions of where and how their files are run.
So I think it's fair to ask in reply to someone implying that `dpkg --root=$HOME -i mypackage.deb` is as clean/same as a flatpack behaviour "It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb!"... It's fair to ask "where do those files in the deb package go ?" because if it works as implied (no pollution of the OS) I am certainly going to start testing installing things that way.
"I don't see how randomly installing a Flatpak is any worse for security than compiling the source myself."
It's worse because you're likely to install more packages using something like Flatpak than you would by downloading random binaries or building from source. That wantonness isn't justified given the current state of security on Linux.
(I'm just regurgitating OP: "Flatpak and Snap apologists claim that some security is better than nothing. This is not true. From a purely technical perspective, for apps with filesystem access the security is exactly equal to nothing. In reality it’s actually worse than nothing because it leads people to place more trust than they should in random apps they find on the internet.")
> It's worse because you're likely to install more packages using something like Flatpak than you would by downloading random binaries or building from source.
... what makes you say that ? if I want to run something, it'll run one way or another no matter how hard the "system" wants to prevent that. Even if it's patch.exe downloaded from a 2004 russian website.
No. It doesn't. You still need to trust the people who package the thing.
A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it works against you!
EDIT: The "dependency hell" issue is separate, and is solved more easily by distributing static binaries.
> No. It doesn't. You still need to trust the people who package the thing.
Flatpak and Snap have never claimed to solve the trust issue though. Flatpak allows you to add your own repositories and thus developers can package their own applications. So if you trust the developer enough to run their software, you should be able to trust them to package their own app with.
I don't entirely disagree with this point, but i'd like to point out that running a program as a tarball/appimage downloaded from the dev's website places entire trust in the project's infrastructure, where on the other side of the spectrum distro packaging relies on strong vetting from a distro's community.
Flatpak/snap is somewhere in between where on the main repos (eg. flathub.org) anyone can publish a package for anything without being affiliated with upstream. It incentivizes users to just search for the app name and download whatever comes up as a result. That's a pattern we've known to be broken for years: from Windows users downloading the first link Google suggests (usually a sponsored link bundled with spyware/adware) to Android users downloading anything the Play Store suggests (usually spyware, see how many flashlight apps there are and what permissions they require). F-Droid in the Android ecosystem strikes a balance because there is strong community vetting for all packages published, so it's like a distro-agnostic repository following the distro packaging threat model.
I believe there are ways to mitigate those issues (eg. namespace enforcement on flatpak) but i don't think downplaying them is doing any good.
You are right. But with the marketing of them with sandboxing and whatnot, they create the impression and illusion that it is safe. Cos most of them install it from Flathub or Snapcraft. The assumption is that they go through all of it and that it is safe. Just like Play store and App store. I am pretty sure Flatpak folks now this. It is like... we won't lie. But we are not also gonna tell the truth.
To make things worse, Flathub changed the way they display "Publisher" field for a flatpak. Which says whether a package was published by Flathub maintainers, Upstream developer or somebody else in Flathub. Now instead of saying who, they just say a "See details" link under Publisher field in flathub.org for a flatpak. That link which in turn directs me to a github page and I am still unsure who the hell uploaded that flatpak.
Before, they used to say Upstream developer's name or say "Flathub maintainers" which means Flathub team uploaded the flatpak making it easier verify who uploaded the flatpak. But now it is making it more difficult. This has been the most pissing thing about Flatpak other than the security issues and problems which keeps coming up about Flathub every now and then. Why would you change something that is so crucial when it is working?
Cos now, I could package a software which is not in Flathub and it would just say "See details" instead of my name. This provides the illusion of trust. Cos if it were to show my name there, more people would've been like.. who the hell is this guy and do a check on me (I used to do that). But now, If I could slip through Flathub checks and provide malicious flatpak, majority of the folks will still install cos most of them are using Flatpak for convenience. Not security and performance.
Want proof? Just scroll up and you will see someone saying he don't care even though agrees to the things in the blog post. He just don't care. :shrug:
I was thinking about this the other day and a wasteful solution to the packaging problem in open source is the decentralized build solution on a blockchain like platform. Either with PoW or PoS. In PoS, a node builds the code pulled from source control, multiple other nodes validate the build and its hash and add to the blockchain and to the repository. Now the builds are relatively trustable. Of course need to figure out an incentive structure for miners/validators to do this expensive work.
Maintainers are not developers, they are users, so the developer cannot push unwelcome changes, such as ads, trackers, trojans, backdoors, keyloggers, etc. directly to users because the maintainer will refuse to accept that.
On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained"), which reflects poorly on the developer in the mind of the user.
I personally see no upside to shoving an unpaid third party between user and developer.
> I personally see no upside to shoving an unpaid third party between user and developer.
I think F-Droid is a good example of striking a balance between those two extreme models. Their existence enforces community vetting of apps as well as somewhat-reproducible thanks to their standardized build infra, which are two major wins.
I personally have much more trust in such schemes (such as guix/nix) because i don't necessarily trust all of the developers of apps i use not to get hacked, and i believe enabling one-click updates to every user of an app without review is a dangerous pattern for security.
> On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software,
Such maintainer will be kicked off from distribution.
> and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained")
Developer wishes are developer wishes. User wishes are more important. If package has a maintainer, then it IS maintained.
You can use any distribution developed by developers (do you know any?) if you dislike maintained distributions and share experience with us.
> Such maintainer will be kicked off from distribution.
ORLY? What's Kurt Roeckx[0] up to these days? Oh right, he's the Debian Project secretary, despite famously crippling RNG in OpenSSL.
> Developer wishes are developer wishes. User wishes are more important.
You mean like the wish to get up to date software directly from the developer without waiting for some third-party middleman to get around to updating the repo?
> You can use any distribution developed by developers (do you know any?) if you dislike maintained distributions and share experience with us.
Such a beast doesn't seem to exist in the Linux world, so I just don't use Linux. Linux Desktop's abysmally low market share may or may not be related.
[0] To be fair to Kurt, he wasn't the only one who didn't see a problem removing those lines and he did ask around first. It is an understandable mistake and I don't mean to crucify him.
> Such maintainer will be kicked off from distribution.
Debian did this, they said oops and moved on. Packagers suck as developers, they apply patches they don't fully understand to solve problems they don't understand on codebases they don't understand.
This is an inherent limitation of the way OSs are built. Linux, Windows, macOS are all like this. macOS is currently the furthest ahead in this since they're sharing code with iOS, but it's still not where it should be.
The Linux kernel is not at a point of allowing this kind of fine grained sandboxing or mocking of APIs. I'm guessing because it's a significant undertaking. I'm sure as more features become available in the Kernel w.r.t. sandboxing Snap and Flatpak will definitely utilise them.
That's only true for the simplest of apps. The whole point of desktop OSs is that programs can integrate with each other, but that necessarily discards the notion of a sandbox almost entirely.
Yeah, e.g. file sandboxing approaches that work along the lines of "don't let the program access any files outside of its private directory except for those explicitly and lovingly hand-picked by the user" commonly ignore the existence of multi-file file formats.
> Is there any difference in trust between package maintainers and flatpack packagers?
Yes, and very big: Debian maintainers need to build a reputation for years to gain upload rights, meet in person, sign keys, and the packages are peer reviewed my multiple persons.
Plus, packages spend time in release freeze being tested by a large userbase before a distro is released.
You can override permissions (there is even a GUI called Flatseal for that). You are also not able to do any of that with distro package managers like apt or dnf. Ultimately you need to trust either.
What I mean is that permissions and accesses concern the operating system, not the software packaging. I don't understand why flatpack needs to deal with those, providing a false (and pernicious) aura of protection. I already run third-party software inside containers or virtual machines. No need for a GUI nor a flatpack-only solution like flatseal. It just looks pointless.
apt is not misleadingly advertised as a sandboxing environment. Flatpack is:
"Flatpak: Linux application sandboxing and distribution framework " [0]
"It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1]
The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack proposition is directly contradictory with this basic requirement, in that it requires the application to be flatpacked to begin with.
When I use something from a distribution, I trust the distribution as organization. When I use something packaged by a developer, I trust the developer. I cannot verify thousands of developers, so I must trust the distribution and I can trust few developers or packagers outside of distribution.
Yes, but only for things you give access to (data files, internet)... sandboxing by default, it should not be able to do anything except consume CPU (memory needs to be limited also, which might be an issue in practice).
I think it's great, but we're still far off from an ideal solution because it's not exactly fine-grained. For example, flatpak portals enable me to grant/block access to my home folder, but don't enable me to allowlist a specific folder in my home. So i'm stuck with the possibility that a vulnerability in the app can take over my entire system (eg. by rewriting ~/.profile), or with my app not accessing my home folder at all.
As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.
>As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.
The filesystem permissions are a bit more fine-grained than "all of home or nothing". Your two examples are already possible to achieve by granting filesystem access to xdg-documents or xdg-downloads.
So many flatpaks do this incorrectly though. For Browser by default saves in the flatpaks home/Downloads directory (which is 15 layers deep from ~). You just gotta know to navigate up.
Signal let's you save attachments anywhere on disk, but only if you manually navigate to ~/Downloads, does it actually save (in a way visible and accessible outside of the app). You just gotta know.
I forgot what exactly the problem was with Vscode(/ium), but it also has a catch like that. You just gotta know.
Flatpak turns out to be the best compromise between distribution and cross distro compatibility, but there's still some low hanging fruit that could be improved.
It's not true they assume full write access to ~, they just don't propagate they limitation of a constricted choise of paths in their GUIs. Because they isn't a way to do that, GUI toolkits don't really provide a way to clearly communicate you can only save/open in a specific dir.
I download a Flatpak from the Pop OS store and it works. It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb!
I've never got into dependency hell where I need to apt-get a specific version of a library from a dodgy PPA.
If I uninstall it, Flatpak doesn't leave acres of cruft strewn around my disk.
I don't see how randomly installing a Flatpak is any worse for security than compiling the source myself. The permission model on Linux is far worse than Android - so I just hope for the best anyway.
Snaps never worked right for me - and seemed to frequently break. But all my Flatpaks have run fine and at full speed.
Does it take up more disk space? Sure. But that's a trade-off I'm willing to make in order to just download and run with no extra work.
Sure, there are some efficiency and security gains to be made. But I'm much happier with a Flatpak world than the alternative.