> <i>Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security.</i><p>Sheesh, while the issues raised are all valid, this does not actually justify such a conclusion about the intent of the Red Hat developers. Telling people what their side of the story is for them in a dismissive fashion like this is not going to make it more likely that they admit their mistakes.<p>A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human cooperation (of any kind) more smoothly.<p>[0] <a href="https://en.wikipedia.org/wiki/Hanlon%27s_razor" rel="nofollow">https://en.wikipedia.org/wiki/Hanlon%27s_razor</a>
Cross-posting a comment from Reddit, because it nails one of the points mentioned:<p>---<p>The list on the page is<p><pre><code> Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ...
</code></pre>
With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action causes a prompt.<p>Now, that's not to say this is good as it is, but for most listed programs it's probably the way to go.
The developers are employed by Red Hat, but that does not make this a Red Hat endorsed product. It is not included in the current offering of RHEL and unlikely would be in a new(er) version as the technology is immature/not well enough tests d/proven yet for inclusion within EL. I call the usage of 'Red Hat' here clickbait and sensationalism as there is no indication within the text that shows the aforementioned non-existence of endorsement or inclusion.<p>Note: the engineers working on Flatpak and both friends and colleagues of mine. Just concerned that the author misrepresents our employers viewpoint. We are allowed to work on side projects, but that does not make them default inclusions or endorsed.
1. None of this has anything to do with Flatpak, it has everything to do with Flathub and how particular software is packaged.<p>2. Your preferred distribution can host their own Flatpak repository and ensure that things like security updates get dealt with properly. Flatpak is not Flathub.<p>3. This ecosystem is growing, so it's putting some things on the backburner, prioritizing application availability over holding a package to make sure that permissions are perfect. There is no reason that these issues can't be ironed out going forward.
Ugh. This trade off again. Linux package management means you update a library once, and fix that security problem everywhere for all the apps that use that library .. except for Firefox, Libreoffice, Chrome and others which insist on packaging their own versions of libjpeg, libpng and everything under the sun for stability.<p>A docker container contains all its own dependencies too. You gain stability .. but you could have a bedbug nest of security problems down there.<p>I don't get the move to Flatpack and Snap for desktop apps. Desktop apps need to interact with the base OS, the display system (X11 or Wayland) the shared toolkit libraries (GTK/QT). I've screenshots of native vs Flatpack vs Snap and they tend to have different window borders, some get the GTK themes matched up while others don't.<p>Not to mention the wasted space when every single application has its own version of everything. What, did you think electron apps each packaging their own 80MB web browser was a good idea too?<p>This just seems like the wrong direction to move in for Linux. We're not MacOS! We don't have hacked together shit like Android apks. We need to be better than that!
> CVE-2018-11235 reported and fixed more than 4 months ago. Flatpak VSCode, Android Studio and Sublime Text still use unpatched git version 2.9.3.<p>Wait, what? We explicitly do not ship a Flatpak version of Sublime Text, and no version of Sublime Text comes with git.<p>After such inaccurate information, I can’t help but question the rest of the article.
Could someone knowledgeable enough comment on how this compares to Cannoicals Snappy <a href="https://en.wikipedia.org/wiki/Snappy_(package_manager)" rel="nofollow">https://en.wikipedia.org/wiki/Snappy_(package_manager)</a>?
Flatpak, Snap, container images are the new iteration of static linking.<p>Just like with static binaries, they make deployment easier for the developer, but introduce problems with size, duplication and library updates.<p>Flatpak added runtimes [1] to alleviate the problem. Does this solution look familiar? Yes, it is the same dynamic library concept. We are coming full circle.<p>[1] <a href="http://docs.flatpak.org/en/latest/available-runtimes.html" rel="nofollow">http://docs.flatpak.org/en/latest/available-runtimes.html</a>
> VLC [...] filesystem=host<p>See my comment on why it's not easy to fully sandbox software like VLC:
<a href="https://news.ycombinator.com/item?id=14409234" rel="nofollow">https://news.ycombinator.com/item?id=14409234</a><p>The author is correct, in the fact that flatpak-vlc is not a secure sandbox.
By default, flatpaks don't have r/w to your home.<p>And setuid binaries have been blocked for a while (as the article says). Plus, selinux will have these things locked down on a system that uses selinux.<p>I think the problem is part perception. Flatpak, like Docker is not primarily for security isolation. It's isolation for ease of deployment - to avoid dependency hell.<p>Not saying Flatpak's failings are not a problem. Just keep some perspective.
To be honest, this security nightmare also covers other contemporary "container" formats such as docker.<p>Running docker containers as a non-root user is unfortunately still not a widespread practice. That means that any root process within a docker container has root on the host.
What a lot of people are missing is that flatpaks put the flatpak author responsible for the security of every package inside the flatpak. If you use a package from an unofficial rpm or deb repo, they're nearly always still dynamically linked, so security updates for things like openssl still apply.
This is what happens when you try escape "dependency hell" by turning the host into a composition of hosts-per-application.<p>Now you have a clusterfuck of dependency islands which all need updating and have their own unique sets of CVEs and upstream release schedules and policies.<p>It's not really flatpak-specific, this is the reality of containers (in the image/rootfs software distribution sense, not namespaces+cgroups) in general.
Flatpak and Flathub are not hiding this and nowhere on Flathub does it claim that all Flathub apps are securely sand boxed. Flathub has unoffical packages and this it has the same issue like all other unoffical repos.<p>Flatpak CAN be used to do sandboxing, but that totally different from saying 'all application will be securely sandboxed'. I don't know where the authors got this idea from.<p>The simple fact is, that sandboxing on a legacy system is difficult and Flatpak can't magic away many of the security issues in the Linux desktop.<p>Also all the 'Red-Hat Developers' evil reminds me of the typical Systemd-hate rant and I really hope we don't have to suffer another iteration of this in the Open-Source community. The person that leads the project works for Red Hat, but its not a Red Hat project.
I share this writer's concerns with Flatpak. It looks to me like yet another attempt to bring the horribly broken and insecure "download it and drag it to your desktop" model of application distribution, which has long been a source of viruses and malware on Windows and Macs, to Linux.
The sandbox is in a sense working, the problem is that the folder the app accesses is more critical than what the user thought. We should make sure nothing in home will get executed : no bashrc, no scripts, no executable. In the "ideal" world you would never download & run any script or any executable (like on Android or IOS). Everything the user should be able to do is install or run flatpak apps.<p>(Of course in practice as soon as you are programming a bit you'll want to open a terminal, run scripts and do stuff outside flatpak)<p>For the second point, well it's just that update are not frequent enough ? This has nothing to do with flatpak technology right ?
I don't see any real benefits to using flatpak in its current form. You get worse integration with the rest of the system, poor tools that are inferior to your system's package manager, and no real security benefits currently. What's the point of launching all these rubbish proprietary apps on the store with no real sandboxing ? It creates a false sense of security, which is worse. All the proprietary apps will do what they used to. They've just been ported to flatpak as thin wrappers. If you get the dropbox flatpak, it will continue to litter your home directory with hidden files.
flatpak is still early.. most apps are still installed from package managers, and few apps are written with flatpak in mind.<p>The current situation is probably not much worse than installing from various third party package archives.<p>I suspect things will get better as adopting catches on.. it's no surprise that early stage open source software have rough edges.
Trust me, nobody cares. The regular user doesn't go past "I can install Spotify in one click". It always were like that and it always will be like that. With more "normies" coming to Linux there will be more stuff like that. That is exactly why people were saying that there are no viruses on Linux only thanks to lower popularity.<p>And with all honesty - how many of us read script files when installing something from AUR?<p>But hey, nobody forces you to use it! You can always choose you distro repo or go DIY way.
Random mint 18.04 user here.<p>I just noticed about a week ago that flatpak was downloading huge amounts of data (like hundreds of MBs).
I had all system updates set to download and install manually, and hadn't installed anything new for at least a month. All this data was getting sent to /var/tmp as flatpak-cache folders.<p>I don't know what it was doing but I've since turned it off in the startup list. Any ideas? What are the chances this was malicious?
What's cross-platform experience for packagers/builders? Seems like you can't do cross-compilation, so expecting upstream to provide flatpaks for users is expecting upstream to manage virtual or real machines for every [desired] CPU architecture with all the annoying host distro installation/management, networking stuff, etc.?<p>At least with the current model, upstream developers can offload most of that to distribution packagers.
> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue.<p>The flatpak release notes talk of a "minor security update", where "minor" surely means "of small size", not "of little importance" as OP would have it. Though the text could add a little importance.
Disclaimer: I work for Red Hat<p>I strongly oppose these kind of attacks by people hiding their identity. No matter how valid the criticism might be, this goes against all the ethics of Open Source.<p>Just like the Devuan folks that vigorously attacked systemd and Lennart.<p>This must not be tolerated.<p>Yes, I’m very upset.
> Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions<p>Aren't other sandboxes (like Ubuntu's Snap) the same?
<i>"Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions, that is, write permissions to the user home directory (and more), this effectively means that all it takes to "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's it."</i><p>No shit, installed applications can write to the filesystem. What an exceptional security hole that only affects flatpak and literally every other form of installing those same programs outside of a sandbox.
This is especially bad for projects like Linphone (open source SIP Client) which exclusively provide Flatpak-builds for Linux [1].<p>[1]: <a href="http://www.linphone.org/technical-corner/linphone/downloads" rel="nofollow">http://www.linphone.org/technical-corner/linphone/downloads</a>
oy. i'm not at all familiar with it but the author comes off as being on his game so i'll take it at face value.<p>beyond disappointing that RH would release such a thing.