Flatpak is kind of bringing the BSD mindset of base system versus end-user apps to Linux.
Back in the glory days of FreeBSD, one would have system libraries managed by the FreeBSD team, and then whatever libraries the ports system used in /usr/local/lib which were used for end-user applications. Everything not provided by FreeBSD came from ports and was installed in /usr/local (/usr/local/bin; /usr/local/etc; /usr/local/lib; etc) so you would have two versions of gcc, for example.
With Flatpak, you have your stable, or rolling base, whatever you are comfortable with. In my case, Debian. And it is fully separate from the end-user applications. This is something that I’ve really missed since coming to Linux from BSD. I can keep Firefox bleeding edge without having to worry that the package manager is also going to update the base system, giving me a broken next boot if I run rolling releases.
Conversely, I don’t have to wait for backports from my underfunded, understaffed distro’s security team, or ride Firefox ESR.
End-user applications are in containers. So what ffmpeg in the VLC flatpak has an exploit, VLC can only access your ~/Videos directory anyway. It’s not going to read your PKI certs or send your ssh keys off somewhere.
Use flatseal to manage permissions of each app.
It’s not perfect, but it’s a step in the right direction.
FWIW, OpenBSD has done this for years with Chrome and Firefox, which only have ~/Downloads access.
If you run KDE Plasma 5.27 or later, flatpak permission settings are included right from the system settings. A built-in flatseal, in case anyone didn’t know.
https://i.imgur.com/PSdt6iy.png
I can keep Firefox bleeding edge without having to worry that the package manager is also going to update the base system, giving me a broken next boot if I run rolling releases.
On Nix[OS], one can use multiple base Nixpkgs versions for specific packages one wants. What I have is e.g. 2 flakes nixpkgs, and nixpkgs-update. The first includes most packages including base system that I do not want to update regularly, while the last is for packages that I want to update more regularly like Web browser (security reasons, etc).
Flatpak is kind of bringing the BSD mindset of base system versus end-user apps to Linux.
What must one not read. The reason is that FreeBSD develop and maintains the whole base system: kernel + system related frontend and because it’s a clean architecture.
For the isolation they had jails before containers was a thing.
Flatpak was not about sandboxing, this aspect is quite recent. It is a response to how bad the CI-pseudoCD was for Gnome and to build/deploy apps based on gnome-stack easily. For proprietary product, I still have to see it a proprietary product not available outside flatpak…
Don’t get me wrong, it’s good that Flatpak tackle the sandboxing question that was not what was sold previously. Also, I use official repos and mainly FOSS. Flatpak won’t prevent a supplychain attack. So my trust remains the main repos.
Flatpak is kind of bringing the BSD mindset of base system versus end-user apps to Linux.
Back in the glory days of FreeBSD, one would have system libraries managed by the FreeBSD team, and then whatever libraries the ports system used in /usr/local/lib which were used for end-user applications. Everything not provided by FreeBSD came from ports and was installed in /usr/local (/usr/local/bin; /usr/local/etc; /usr/local/lib; etc) so you would have two versions of gcc, for example.
With Flatpak, you have your stable, or rolling base, whatever you are comfortable with. In my case, Debian. And it is fully separate from the end-user applications. This is something that I’ve really missed since coming to Linux from BSD. I can keep Firefox bleeding edge without having to worry that the package manager is also going to update the base system, giving me a broken next boot if I run rolling releases.
Conversely, I don’t have to wait for backports from my underfunded, understaffed distro’s security team, or ride Firefox ESR.
End-user applications are in containers. So what ffmpeg in the VLC flatpak has an exploit, VLC can only access your ~/Videos directory anyway. It’s not going to read your PKI certs or send your ssh keys off somewhere.
Use flatseal to manage permissions of each app.
It’s not perfect, but it’s a step in the right direction.
FWIW, OpenBSD has done this for years with Chrome and Firefox, which only have ~/Downloads access.
If you run KDE Plasma 5.27 or later, flatpak permission settings are included right from the system settings. A built-in flatseal, in case anyone didn’t know. https://i.imgur.com/PSdt6iy.png
On Nix[OS], one can use multiple base Nixpkgs versions for specific packages one wants. What I have is e.g. 2 flakes nixpkgs, and nixpkgs-update. The first includes most packages including base system that I do not want to update regularly, while the last is for packages that I want to update more regularly like Web browser (security reasons, etc).
e.g.
What must one not read. The reason is that FreeBSD develop and maintains the whole base system: kernel + system related frontend and because it’s a clean architecture. For the isolation they had jails before containers was a thing.
Flatpak was not about sandboxing, this aspect is quite recent. It is a response to how bad the CI-pseudoCD was for Gnome and to build/deploy apps based on gnome-stack easily. For proprietary product, I still have to see it a proprietary product not available outside flatpak…
Don’t get me wrong, it’s good that Flatpak tackle the sandboxing question that was not what was sold previously. Also, I use official repos and mainly FOSS. Flatpak won’t prevent a supplychain attack. So my trust remains the main repos.