5 ms·

I've contributed to flathub, so I might be biased, but what I never got about the "flatkill" rant (which was first posted like 3-4 years ago) is that flatpak ha

I've contributed to flathub, so I might be biased, but what I never got about the "flatkill" rant (which was first posted like 3-4 years ago) is that flatpak has never claimed to be a security panacea. They didn't invent flatpak for the sake of security. Flatpak is fundamentally a distro-agnostic packaging mechanism and build environment with some clever abstractions to avoid static linking and encourage code reuse. Theoretically, it's also got the potential to make things more secure, but it wasn't ever billed as the main idea. My dad was always a windows guy, but recently I got him using linux mint for some of his ham radio stuff. Flatpak and flathub are perfect for people like him. And that's good enough.

pydry 6y ago
I got the same impression. Flatpak seemed much more like 21st century static linking with some slowly evolving security features bolted on top. The other thing I didn't get about the flatkill rant was why it didn't put flatpak in context. It makes much more sense compare the security of flatpak to that of appimage and snap than to look at flatpak as an isolated thing.
- stuaxo 6y ago
  Yep - perfect is the enemy of good. For me the advantage of flatpak is that it makes things a lot easier to install, abstracting away all the detail between different Linux distros. The layering is good + because of immutability, you have a system that is a lot closer to the one the devs actually used. There is a little more security, which is a bonus too, but that's not the main draw.
- lrvick 6y ago
  To be fair the default software supply chain integrity story and sandboxing of docker, snap, and appimage are also terrible. They all solve the same "problem". Without dedicated parties to maintain updates... like a distro, most of the packages distributed with these tools just make Linux less secure even if the tools themselves are useful in right context. The docs and authors of these tools are trying to bring to Linux the "go on the internet and get a random .exe" model of Windows which is a proven security nightmare.
- rkeene2 6y ago
  If you like that concept, then AppFS [0] is even more interesting since it removes the "install" step. CernVMFS [1] is very similar to AppFS, though AppFS has more features. [0] https://appfs.rkeene.org/ https://appfs.rkeene.org/ [1] https://cernvm.cern.ch/fs/ https://cernvm.cern.ch/fs/
glsdfgkjsklfj 6y ago
> flathub are perfect for people like him > justifying a solution you would never use yourself because there are dumb users. I would understand dismissing power users by profit factories (e.g. https://tedium.co/2021/01/27/power-users-history/ https://tedium.co/2021/01/27/power-users-history/ ) but not in open source i would ever have dreamed of it.
nebulous1 6y ago
Perhaps the messaging has changed or I came at it from a different angle, but my memory is that when I first investigated flatpak they promoted the security aspect of the sandbox, and that I was later genuinely confused when I found out that the apps could specify their own sandbox setting without specifically asking me on install.
- vetinari 6y ago
  There is security aspect of the sandbox, but that does not mean it is turned up to the 11 for every single package since day 1. Especially if the result is, that it would break or make unusable the package. No, the intent is to have evolution: provide a mechanism for some scenarios, update apps where possible, provide for more scenarios, update additional apps, and improve continuously, till you achieve the securing aspect. Treating it as if it was a flip of the switch, and then badmouthing it when it turns out it is not, is not a good faith contribution.
  - sthnblllII 6y ago
    Flatpak sandboxes are security theater. The goal of the sandbox is fantastic. But until apps are actually sandboxed they shouldn't call it a sandbox. "Trivially bypass-able security is better than no security" is just a bad thing to have to say to defend something.
    - vetinari 6y ago
      Again, it is not something that can be done with a flip of a switch, across the entire ecosystem. Rome wasn't built in a day either.
      - sthnblllII 6y ago
        I agree. Now why is it called a sandbox if it isnt one?
        vetinari 6y ago
jcelerier 6y ago
https://web.archive.org/web/20160624093121/http://flatpak.org/ https://web.archive.org/web/20160624093121/http://flatpak.or... > Sandboxes > Flatpak isolates apps from the host OS as well as from other applications. This provides security for users and a predictable environment for developers.
- nickysielicki 6y ago
  Nice of you to leave off the only remaining sentence in that paragraph: > (Some of these features are work in progress) But seriously, there's nothing inconsistent here. All the major headings on that page are about distro-agnostic app distribution, build environments, and portability. The fact that flatpak has mechanisms for sandboxing that go largely unused on flathub doesn't mean that flatpak misrepresented itself as secure. In an alternative universe, on a private flatpak repository, flatpak (as a technology) facilitates secure sandboxed desktop applications. It just didn't turn out that way in our universe, or at least, not yet.
  - jcelerier 6y ago
    > Nice of you to leave off the only remaining sentence in that paragraph: > (Some of these features are work in progress) I left it off because it doesn't change anything when talking about the announced goals ? > But seriously, there's nothing inconsistent here. All the major headings on that page are about distro-agnostic app distribution, build environments, and portability. The fact that flatpak has mechanisms for sandboxing that go largely unused on flathub doesn't mean that flatpak misrepresented itself as secure. https://docs.flatpak.org/en/latest/sandbox-permissions.html https://docs.flatpak.org/en/latest/sandbox-permissions.html > One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment. how can it be written more clearly ? hell, the first press release has "security first" as headline: https://flatpak.org/press/2016-06-21-flatpak-released/ https://flatpak.org/press/2016-06-21-flatpak-released/
    - 6y ago
pengaru 6y ago
> They didn't invent flatpak for the sake of security [citation needed] Alex Larsson speaks to the "security model" in his blog posts. [0],[1],[2] Without a strong security/sandboxing story, there is no flathub or general confidence in running binaries received directly from developers vs. the traditional distro model. Distros have historically served as trusted arbiters. One of Flatpak's stated goals is to bypass distros in the interests of enabling end-users to more closely track developer releases of software. This exposes end-users to substantial risks, and Flatpak relies on sandboxing to mitigate those risks. I find it obviously inconsistent with Alex's posts for Flatpak's GUI to claim apps are sandboxed, when they're directly accessing the host filesystem and/or user's home directory, and don't utilize portals. [0] https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-security-model-part-1-the-basics/ https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-securit... [1] https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-security-model-part-2-who-needs-sandboxing-anyway/ https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-securit... [2] https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-model-part-3-the-long-game/ https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-securit...
enriquto 6y ago
> clever abstractions to avoid static linking the really clever thing would be to embrace static linking
- vetinari 6y ago
  You cannot really have static binary on modern linux with contemporary glibc. Unless you intend to break services NSS, that is. Even golang runtime checks for NSS config before ignoring glibc.
  - enriquto 6y ago
    This is indeed a major and shameful bug of GNU libc. There's no fundamental reason why NSS services cannot be statically linked. My pet conspiracy theory is that some glibc authors were anti-static linking fanatics (probably Drepper), and tried hard so that it was difficult to static link. Fortunately, we have musl libc where static linking works without trouble, and by the way produces smaller binaries.
    - vetinari 6y ago
      NSS modules are actually plugins, so they have to be dynamic. They don't have to be shipped with glibc, other libs can ship their own, or even be standalone. For example, nss-mdns used to be standalone, or nss-resolve ships with systemd-resolved.
      - yencabulator 6y ago
        NSS should have been a service spoken to over e.g. UNIX domain sockets.

pydry 6y ago

I got the same impression. Flatpak seemed much more like 21st century static linking with some slowly evolving security features bolted on top. The other thing I didn't get about the flatkill rant was why it didn't put flatpak in context. It makes much more sense compare the security of flatpak to that of appimage and snap than to look at flatpak as an isolated thing.

stuaxo 6y ago
Yep - perfect is the enemy of good. For me the advantage of flatpak is that it makes things a lot easier to install, abstracting away all the detail between different Linux distros. The layering is good + because of immutability, you have a system that is a lot closer to the one the devs actually used. There is a little more security, which is a bonus too, but that's not the main draw.
lrvick 6y ago
To be fair the default software supply chain integrity story and sandboxing of docker, snap, and appimage are also terrible. They all solve the same "problem". Without dedicated parties to maintain updates... like a distro, most of the packages distributed with these tools just make Linux less secure even if the tools themselves are useful in right context. The docs and authors of these tools are trying to bring to Linux the "go on the internet and get a random .exe" model of Windows which is a proven security nightmare.
rkeene2 6y ago
If you like that concept, then AppFS [0] is even more interesting since it removes the "install" step. CernVMFS [1] is very similar to AppFS, though AppFS has more features. [0] https://appfs.rkeene.org/ https://appfs.rkeene.org/ [1] https://cernvm.cern.ch/fs/ https://cernvm.cern.ch/fs/

glsdfgkjsklfj 6y ago

> flathub are perfect for people like him > justifying a solution you would never use yourself because there are dumb users. I would understand dismissing power users by profit factories (e.g. https://tedium.co/2021/01/27/power-users-history/ https://tedium.co/2021/01/27/power-users-history/ ) but not in open source i would ever have dreamed of it.

nebulous1 6y ago

Perhaps the messaging has changed or I came at it from a different angle, but my memory is that when I first investigated flatpak they promoted the security aspect of the sandbox, and that I was later genuinely confused when I found out that the apps could specify their own sandbox setting without specifically asking me on install.

vetinari 6y ago
There is security aspect of the sandbox, but that does not mean it is turned up to the 11 for every single package since day 1. Especially if the result is, that it would break or make unusable the package. No, the intent is to have evolution: provide a mechanism for some scenarios, update apps where possible, provide for more scenarios, update additional apps, and improve continuously, till you achieve the securing aspect. Treating it as if it was a flip of the switch, and then badmouthing it when it turns out it is not, is not a good faith contribution.
- sthnblllII 6y ago
  Flatpak sandboxes are security theater. The goal of the sandbox is fantastic. But until apps are actually sandboxed they shouldn't call it a sandbox. "Trivially bypass-able security is better than no security" is just a bad thing to have to say to defend something.
  - vetinari 6y ago
    Again, it is not something that can be done with a flip of a switch, across the entire ecosystem. Rome wasn't built in a day either.
    - sthnblllII 6y ago
      I agree. Now why is it called a sandbox if it isnt one?
      - vetinari 6y ago

jcelerier 6y ago

https://web.archive.org/web/20160624093121/http://flatpak.org/ https://web.archive.org/web/20160624093121/http://flatpak.or... > Sandboxes > Flatpak isolates apps from the host OS as well as from other applications. This provides security for users and a predictable environment for developers.

nickysielicki 6y ago
Nice of you to leave off the only remaining sentence in that paragraph: > (Some of these features are work in progress) But seriously, there's nothing inconsistent here. All the major headings on that page are about distro-agnostic app distribution, build environments, and portability. The fact that flatpak has mechanisms for sandboxing that go largely unused on flathub doesn't mean that flatpak misrepresented itself as secure. In an alternative universe, on a private flatpak repository, flatpak (as a technology) facilitates secure sandboxed desktop applications. It just didn't turn out that way in our universe, or at least, not yet.
- jcelerier 6y ago
  > Nice of you to leave off the only remaining sentence in that paragraph: > (Some of these features are work in progress) I left it off because it doesn't change anything when talking about the announced goals ? > But seriously, there's nothing inconsistent here. All the major headings on that page are about distro-agnostic app distribution, build environments, and portability. The fact that flatpak has mechanisms for sandboxing that go largely unused on flathub doesn't mean that flatpak misrepresented itself as secure. https://docs.flatpak.org/en/latest/sandbox-permissions.html https://docs.flatpak.org/en/latest/sandbox-permissions.html > One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment. how can it be written more clearly ? hell, the first press release has "security first" as headline: https://flatpak.org/press/2016-06-21-flatpak-released/ https://flatpak.org/press/2016-06-21-flatpak-released/
  - 6y ago

pengaru 6y ago

> They didn't invent flatpak for the sake of security [citation needed] Alex Larsson speaks to the "security model" in his blog posts. [0],[1],[2] Without a strong security/sandboxing story, there is no flathub or general confidence in running binaries received directly from developers vs. the traditional distro model. Distros have historically served as trusted arbiters. One of Flatpak's stated goals is to bypass distros in the interests of enabling end-users to more closely track developer releases of software. This exposes end-users to substantial risks, and Flatpak relies on sandboxing to mitigate those risks. I find it obviously inconsistent with Alex's posts for Flatpak's GUI to claim apps are sandboxed, when they're directly accessing the host filesystem and/or user's home directory, and don't utilize portals. [0] https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-security-model-part-1-the-basics/ https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-securit... [1] https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-security-model-part-2-who-needs-sandboxing-anyway/ https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-securit... [2] https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-model-part-3-the-long-game/ https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-securit...

enriquto 6y ago

> clever abstractions to avoid static linking the really clever thing would be to embrace static linking

vetinari 6y ago
You cannot really have static binary on modern linux with contemporary glibc. Unless you intend to break services NSS, that is. Even golang runtime checks for NSS config before ignoring glibc.
- enriquto 6y ago
  This is indeed a major and shameful bug of GNU libc. There's no fundamental reason why NSS services cannot be statically linked. My pet conspiracy theory is that some glibc authors were anti-static linking fanatics (probably Drepper), and tried hard so that it was difficult to static link. Fortunately, we have musl libc where static linking works without trouble, and by the way produces smaller binaries.
  - vetinari 6y ago
    NSS modules are actually plugins, so they have to be dynamic. They don't have to be shipped with glibc, other libs can ship their own, or even be standalone. For example, nss-mdns used to be standalone, or nss-resolve ships with systemd-resolved.
    - yencabulator 6y ago
      NSS should have been a service spoken to over e.g. UNIX domain sockets.