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.
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.
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:
If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?
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.
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.
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.
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.
You shouldn't need to trust either. Just the sandboxing system of your OS.
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.
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.
How is this any different than sudo apt install foo?
"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.
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.
[1] https://docs.flatpak.org/en/latest/sandbox-permissions.html#...
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.
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.
Flatpak aware apps (like the ones I develop, or any on elementary OS since flatpak is the native packaging format there) tend to just work.
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.