Hi,
This is a direct response to flatkill.org 2020.
I’ve heard a lot of misinformation about Flatpak spread by the community and by a website called flatkill.org. I took the time to write my own response with the help of Flatpak contributors and developers to debunk the claims of flatkill.org to stop the spread of false information.
Hello, thanks for taking the time to write this answer. The issues outlined on flatkill.org were serious enough, but seeing basically no reply (except “FUD warnings”) from the community made me suspicious.
I understand there’s a lot of tradeoffs at play, but i’m interested in following the debates around specific tradeoffs/issues. But from the flatpak.org website i cannot find the bugtracker or the source code for flatpak ; this could probably be improved.
I like the new UI for sandboxing status including a colored warning when the sandboxing applied is practically useless. This addresses what is in my view the biggest problem.
Last question (sorry i’m curious :D) do you think there’s hope to integrate flatpak concepts (eg. sandboxing portals) with a consistent/reliable/reproducible build system like Nix/guix? They are an amazing approach to software packaging but in my view lack UX/integration concerns that flatpak is trying to solve.
Hello, thanks for taking the time to write this answer. The issues outlined on flatkill.org were serious enough, but seeing basically no reply (except “FUD warnings”) from the community made me suspicious.
I agree that the issues are serious, but what they fail to see is that new technologies always take time to get implemented and adapted. systemd didn’t start off great at the beginning; it had many security vulnerabilities and many bugs, but as time went by, systemd has matured and has become the standard init system.
Technologies outside of Linux have experienced the same thing: Bluetooth, SSDs, Android, and more.
Punching holes in the sandbox (as Flatpak is doing right now) is just a temporary approach. But as time goes by, more applications will start using portals. Qt5 and GTK3 applications already use portals. Firefox uses it, Chromium uses it, Electron is being worked on.
Unfortunately, in terms of security that is easy for the end-user, Flatpak is the best we have. Projects that are close to FreeDesktop, such as systemd, GNOME and Fedora often have been very quick in development thanks to the effort of developers, and I doubt Flatpak will be an exception.
But from the flatpak.org website i cannot find the bugtracker or the source code for flatpak ; this could probably be improved.
Not sure what you meant here exactly, but if you asked for the source code of Flatpak, here you go: https://github.com/flatpak/flatpak.
Last question (sorry i’m curious :D) do you think there’s hope to integrate flatpak concepts (eg. sandboxing portals) with a consistent/reliable/reproducible build system like Nix/guix? They are an amazing approach to software packaging but in my view lack UX/integration concerns that flatpak is trying to solve.
Yes. In fact, that is one of the areas where Flatpak is trying to solve. If you use immutable desktops like NixOS, Guix, Endless OS and Fedora Silverblue, Flatpak can be very useful as it doesn’t need to create a new image everytime you need to install, upgrade or remove something. In fact, Fedora Silverblue and Endless OS use Flatpak by default. As a Fedora Silverblue user here, I have no problem with Flatpak
No much of a response. The sandbox is indeed still a lie. And the response pretty much admits it.
For FlatHub OK but nothing prevent you from providing a Flatpak repo only with sandboxed apps.
Still, nothing makes it trustworthy to end users. If I have to trust a random person on the internet to create a flatpack it’s not more secure than running a binary found on 4chan.
To provide acceptable security to all users a real software supply chain process is needed:
- software and sandbox configuration from upstream developers need to be reviewed by a second pair of eyes: package managers
- package managers work needs to vetted as well through peer review, at least, or more “senior” package managers
- the people involved need to be vetted in the first place
…which is a less meticolous version of what Debian does. Various large companies have similar processes for internal use.
Another clarification: nothing prevents sandboxing application deployed with deb or RPM packages. It’s routinely done for system daemons, for example, and by firejail and similar for applications.
Also nothing prevents bundling dependencies inside a package when there’s a good reason to do so.
Why are you mentioning GitHub that is used by FlatHub project while in my comment I just said FlatHub =! Flatpak?
It was just an example of a random person on the Internet. I rephrased it to clarify.
That’s not the point, Flatpak is like DEB or RPM, at a certain point Debian(-based distros) could offer apps as Flatpak while still using DEB for system packages.
Fedora already provides Flatpak apps and Fedora Silverblue is supposed to only install apps with Flatpak from Fedora’s Flatpak repos, from FlatHub or whatever repo the user decides to add.
Mozilla and Libreoffice are already providing official Flatpak builds.
OpenSUSE’s OBS service supports building Flatpak packages too.
Probably you know you can find a lot of third party apps like Google Chrome that supports Linux by providing DEB and RPM packages on their sites. This has been tje case for ages.
So what’s the difference with Flatpak? It’s even better for the use case of distributing untrustworthy apps because they can be properly sandboxed. Flatpak + Wayland is the minimum to make third party software available on Linux distros. Instead DEB/RPM + X11 are meant only for internal use of the distro you choose to trust. Before Flatpak and Wayland you can’t even talk about Linux distros as a real platforms for third party apps.
Think better about what you want to criticize, because your arguments that follow are never that great.
Another thing is that three of their examples, VSCodium, PyCharm, and Octave, are IDEs. It is crucial for an IDE to have access to home or host filesystems, for Git repositories, and for other external uses, otherwise it is not very useful.
I wish Linux had a modern and easy to use permission system like Android. Not just in Flatpak but in general, maybe built in to the package manager.
Something intuitive and user friendly just like Android though. In DEs it could be configured through their GUI and the hardcore CLI users could use the package manager to change the permissions of the package. Just like how currently programs can complain that there’s “no sufficient permission” when trying to access anything outside of /home, they could do the same for other permissions
Firejail does that and it’s been available in Debian for a good while.
deleted by creator
deleted by creator
I dislike flatpak because the wayland experience sucks with GTK apps unless you’re using Gnome.
E: This has been fixed with the release of Gnome 40
deleted by creator
deleted by creator
I have no technical knowledge on flatpaks, maybe someone can confirm isn’t sand boxing it provides fine for non crucial / system apps like games fine ?
I do wish there was more repositories than flathub however especially because they do not separate non-free apps. I also wish flatpak had dedicated gui app for repo and update management, launching apps etc.
deleted by creator
GNOME Software is one of the only GNOME apps I dislike, it often does not work or loads slowly and uses a lot of memory and the interface is not up-to-date :(
But functionally it would work… What I wish for is Lutris getting flatpak support or preferably brand new app launcher focused on flatpak.
I love Flatpak but FlatHub is too much GNOME-centric, for example if you install Qt apps from FlatHub on Plasma they won’t even use Breeze theme by default.
In general there is too much stuff that is not available on Flatpak. Another example are all the addons available at store.kde.org that would be a perfect use case for Flatpak. And again I don’t know how sandboxed apps should be made aware of system settings changes.
If Flatpak wants to improve it just have to think outside the GNOME box.
Qt Flatpak apps running outside of a KDE session (I run Sway) can’t even use Breeze-Dark. The only dark theme they have available is Adwaita-Dark, and you can only use that if you add a commandline parameter to override the theme with an envvar.
deleted by creator
Anki, Calibre, MuseScore are examples of Qt apps from FlatHub not using Breeze, I’m not aware of any way to fix this and FlatHub maintainers just reply “we stuck to whatever upstream does”.
Instead VLC is an example of Qt app from FlatHub that uses Breeze in Plasma.
Flatpak should have a way to detect the current session is Plasma, install KDE runtime or whatever is needed and makes all its Qt apps use whatever QtWidget theme the user set. Otherwise the Flatpak Qt apps (or at least FlatHub’s in case we come up with a Flatpak repo optimized for Plasma) would always be second-class citizens.
