Re:Flatpak: A security nightmare – two years later
by smichel17 on Friday October 02, 2020 @09:00AM
(#24662116)
Epistemic Status: I've been thinking about this for a while, but have not decided on any conclusions yet.
More and more, I view flatpak-style sandboxing as something kind of like wine. It's very important that it exists, as a stop-gap measure to allow people to run the programs they currently depend on. With wine, that's Windows-only programs; for flatpack it's proprietary applications, while retaining some control over their permissions. But it's not an ideal long-term solution.
Using wine in the ideal way requires creating gigabytes of duplicate files (since you want to run one program per prefix, since they may require different and incompatible tweaks). Both it and flatpak make it harder to write shell scripts and generally to hack on your operating system. More importantly, both solve problems that, while they aren't going away any time soon, could be solved just by using high-quality, trustworthy software that targets GNU/Linux natively, without the downsides of these technological solutions.
So, while I do use both of these technologies and appreciate them very much, I prefer native packages and would rather put my effort toward better supporting people who want to write software that is distributed that way.
More and more, I view flatpak-style sandboxing as something kind of like wine. It's very important that it exists, as a stop-gap measure to allow people to run the programs they currently depend on. With wine, that's Windows-only programs; for flatpack it's proprietary applications, while retaining some control over their permissions. But it's not an ideal long-term solution.
Using wine in the ideal way requires creating gigabytes of duplicate files (since you want to run one program per prefix, since they may require different and incompatible tweaks). Both it and flatpak make it harder to write shell scripts and generally to hack on your operating system. More importantly, both solve problems that, while they aren't going away any time soon, could be solved just by using high-quality, trustworthy software that targets GNU/Linux natively, without the downsides of these technological solutions.
So, while I do use both of these technologies and appreciate them very much, I prefer native packages and would rather put my effort toward better supporting people who want to write software that is distributed that way.