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.
Removed by mod
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.
Removed by mod
It was just an example of a random person on the Internet. I rephrased it to clarify.
Removed by mod
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
I’m running Sway and use flatpak without problems. Do you have an example?
I didn’t see any flatpak app without x11 and fallback-x11 enabled. I am a Devuan MATE user in Xorg.
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.
AFAIK, it integrates well with GNOME Software.
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.
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
There is App-Armor and Ubuntu Touch has implemented it in a way that nearly all apps are confined by it and data-exchange only happens mediated through a software called media-hub.
I think this could be used as a basis for a general system on GNU/Linux as otherwise UT is pretty close to a “normal” Linux (except that they are still on upstart with Ubuntu16.04 and use read-only system images).
But the problem is that normally this kind of app confinement is the first thing regular Linux users complain about when using UT as it restricts the freedom of what apps (and the user) can do. This is IMHO largely why UT adoption on the PinePhone has failed, despite it being the first usable OS on it when the community editions where launched initially.
Projects like Fedora Silverblue head in that direction, don’t they?
Firejail does that and it’s been available in Debian for a good while.
Removed by mod
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.
Breeze is the default theme in Qt apps there. This could be different with OBS Studio which uses its own theme by default but can be changed to Breeze.
Removed by mod
