Flatpak – a security nightmare – 2 years later (2020)
1–10 of 296 posts
Re: Flatpak – a security nightmare – 2 years later (2020)
#2What is the security story for Snap and AppImage?
Re: Flatpak – a security nightmare – 2 years later (2020)
#3Snaps for services, debs for user apps
Re: Flatpak – a security nightmare – 2 years later (2020)
#4All of the examples are apps where the main use is manipulating files on the system.
Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?
Re: Flatpak – a security nightmare – 2 years later (2020)
#5Somebody wrote a response to this: https://theevilskeleton.frama.io/2021/02/11/response-to-flat...
Re: Flatpak – a security nightmare – 2 years later (2020)
#6What is the security story for Snap and AppImage?
AppImage is a convenience layer which doesn't claim to add any security as it provides no sandboxing whatsoever. And the outdated dependencies in images are likely to exist in the AppImage world too.
Re: Flatpak – a security nightmare – 2 years later (2020)
#7Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flat...
I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.
Re: Flatpak – a security nightmare – 2 years later (2020)
#8All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?
Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?
Re: Flatpak – a security nightmare – 2 years later (2020)
#9Somebody wrote a response to this: https://theevilskeleton.frama.io/2021/02/11/response-to-flat...
Interesting part:
> 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. […] They also need additional permissions to work, since making them use portals for all host system file access is technically complicated. Audacity and VLC face similar barriers, but all these applications should eventually be able to use portals instead of direct home or host filesystem access without losing functionality.
Which means that the author still has a point: there are still lots of use cases where the only practical way to use the file-access sandbox is to disable it.
Btw, the post you shared is a much more balanced view on Flatpack than the OP, but after having read it I would still consider Flatpack not being ready for what it advertises.
Re: Flatpak – a security nightmare – 2 years later (2020)
#10All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?
Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?
Passing responsibility of not distributing evil software from the gatekeepers to the user.
Ignores half the point of having a distribution that has a package manager, curated software.