21 ms·

Flatpak: A security nightmare – two years later

377 points by krimeo 6y ago

zaarn 6y ago
My issues with the post start with the tone. It's not a respectful tone, rather aggressive and always flashes me back to people who write similar blogposts about systemd or something else that is new but not accepted by greybeards yet. Fonts and theming are an issue, I agree, however, this isn't entirely the fault of the flatpak maintainers but in part the fault of a fragmented and hard-to-compose linux ecosystem when it comes to their configuration. The IME issue is a problem but I don't think a dynamically linked system would benefit much here. The solution is to make portals between flatpak and the system more extensible and versioned, so that an outside daemon an talk to flatpak apps and potentially flatpak could even try to determine which runtime to use based on what outside portal versions are available.
- simias 6y ago
  I skimmed the article and I don't find the tone super disrespectful. No ad-hominem, no insults to the developers etc... The backlash against systemd was unacceptable because it ended up targeting people and not the technology. Writing an init system shouldn't net you death threats. Beyond this, and not unlike systemd, flatpak has been pushed hard down people's throat by powerful entities within the ecosystem, so it's not surprising that in both cases there has been some intense backlash. I also personally think that in both cases it's warranted.
  - shrewduser 6y ago
    I agree, how thin skinned are people? this seems like valid criticism that wasn't acted on in two years. What is an appropriate 'tone' in this case
    - chekovcodes 6y ago
      Tone is narcissistic and self-important - it does not even tip a hat to address prioritisation or resource constraints - it's just "this is important to me THEREFORE IT IS IMPORTANT, GNASH, WAIL". I also think the author does not understand end-user software - if you package everything up so it is very secure by default, almost nobody will ever use it and nobody will care except the people who are capable of securing it themselves.
    - cycloptic 6y ago
      An appropriate tone would be to press the angle that help is needed and either offer to help patch the applications or mention where contributors can get started. I get the author's concern but there is nothing useful in this article. It's misleading suggesting that the problem is with flatpak when the problem is that certain applications aren't using its full capabilities, aren't configured correctly and are in need patching. Or in the worst case, might need a redesign to fit the sandboxing model. This needs to happen with any sandbox that uses this model, not just flatpak. There is nothing else that can be done about this short of suggesting users switch to a different sandboxing model like Qubes. (Maybe the blog author can try that too and see how it goes, or could develop their own sandboxing model just to see how hard it is on a complex system like Linux)
      - dylan-m 6y ago
        As well as misleading, the article seems outdated? Which is weird, because archive.org's first snapshot of it is today. So, GNOME Software has included a "Permissions" field (which lists an application's specific sandbox holes) since - if I recall correctly - GNOME 3.34: https://i.imgur.com/lCGgA1B.png https://i.imgur.com/lCGgA1B.png. Not perfect, but definitely better than pictured. It's a bit of a shame that people have to use older versions of GNOME in 2020, but then, it's nice that Flatpak makes it easy to run new applications regardless :) Also, I was trying to verify the author's claim about a vulnerable libssh in the gitg package, partly because I was curious whether they'd bothered to report any of these issues upstream. Looks like that was fixed in May: https://github.com/flathub/org.gnome.gitg/pull/12 https://github.com/flathub/org.gnome.gitg/pull/12. Similar story with ffmpeg: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/d7d8582f750e1165fd3fd637f8fcb62104ede2c8 https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/.... So, woefully behind schedule, but, how long was the author sitting on these? It would be more accurate, less irritating, and more persuasive if they simply talked about it after the fact: this happened, various things are wrong with it, it should be avoidable, etc.
        frabbit 6y ago
        The first two CVEs linked in the article do not even exist: whether due to rejection or something else is uncertain.
  - matthiasv 6y ago
    > Beyond this, and not unlike systemd, flatpak has been pushed hard down people's throat by powerful entities within the ecosystem, [...] Sounds like a tinfoil hat theory to me. Powerful entities? Pushed down people's throat? You are free to ignore Flatpak, no one is forcing it on anyone.
- turbinerneiter 6y ago
  It's hard to keep a civil tone if you feel like the world around you is descending into madness, and this is exactly what the authors of this posts feel. Its hard to have a civil discussion if everyone pulls into a direction you deem wrong and your words are never convincing anyone. I have similar resentments when people in my company push for docker on embedded systems, because they are used to docker on the server, and whenever I ask them which problem they are solving on the embedded system with docker, they describe things that are wrong. I don't share the authors strength of opinion on flatpak, although I see the same issues, and I don't want to advertise or excuse strong "tone" - but I understand the frustration.
  - pjc50 6y ago
    > push for docker on embedded systems Aaargh! A particularly odd one as most embedded systems are handled as "images" of some sort - firmware blobs, ramdiscs, imaged HDDs for embedded PCs and so on.
  - kanox 6y ago
    What exactly is wrong with docker on embedded systems? Many have the memory and storage to afford containers and existing established distros like yocto are not very good. I'd much rather deal with Dockerfiles than buildbake.
    - turbinerneiter 6y ago
      What is the problem docker solves?
    - Obsnold 6y ago
      Just to clarify yocto is not a distro but a project that allows you to create your own custom distro. Two yocto builds could be completely different from one another even using different package managers.
      - kanox 6y ago
        Yocto and various derivatives can be used to "build software" in the same way that Dockerfiles can be used to "build software" but using yocto is a much worse experience.
- ylyn 6y ago
  I don't see an issue with the tone. Actually, why are people so concerned about tone nowadays? It matters, but this is perfectly fine. I feel like you can't find anything to nitpick about the post, so you pick on the tone instead.
  - zaarn 6y ago
    I've brought up issues beside tone because of this. In case those aren't enough; I think the issues brought up aren't issues with flatpak. The first issue is with a GUI application on top of flatpak and the second is a packaging issue of the runtimes. These aren't inherently problems with flatpak so I mentally don't count them.
    - steerablesafe 6y ago
      Don't forget lying about sandboxing.
      - dylan-m 6y ago
        Yeah, that's a dubious claim as well. Here is how GNOME Software presents a sandboxed application: https://i.imgur.com/VMsj6mk.png https://i.imgur.com/VMsj6mk.png Is it a bad interface? Sure. Is the list of permissions hard to find? Hell yes. Is the Sandboxed emblem kind of misleading? Yeah. But here (in at least GNOME Software 3.36) you see a list of the relevant permissions available to the application. Nobody is lying here. For contrast, here is an application with a stricter sandbox: https://i.imgur.com/lCGgA1B.png https://i.imgur.com/lCGgA1B.png The point here is both of these are sandboxed. Each sandbox just has particular holes in it. For GNU Octave, more than seems appropriate. Users misunderstand that in the same way people misunderstand "autopilot" and that's a good issue to bring up, but then I don't think non-technical users understand what "sandboxed" means anyway and technical users should be able to take one more gorramn step and learn that "sandboxed" obviously comes with particular limitations [at least in the present day] or it isn't going to do anything.
- sergeykish 6y ago
  You've skipped CVE. Flatpak has a lot of claims [1], author feels them as a lie. And he provides facts in support. Linux "next generation technology" would certainly alert users of insecure application. This does not. The story of themes and dbus shows how hard it is to contain all dependencies. Also there were a lot of claims here that Linux distributions makes no good, static linking is better and libraries would be patched. Now lets switch perspective. Windows users are perfectly fine running closed source software which may contain outdated dependencies. Most of them are not updated anyway. And it has gallery, something Winget still lacks. Looks like next gen. What is cry for open source developer may be fine for consumer. Personally I'm fine with Flatpak, Appimage. There should be some way to install proprietary software. And some starting point to make it safe. [1] https://flatpak.org/ https://flatpak.org/
akerro 6y ago
If I understand correctly, a lot of desktop apps need to rewrite their parts of code to adopt to flatpak, and probably also snap to use the sandbox correctly. This post is therefor not criticizing flatpak but GNU Octave for not having enough dev power to implement it.
- enriquto 6y ago
  > a lot of desktop apps need to rewrite their parts of code (...) to use the sandbox correctly. This is completely backwards. Security features and encapsulation are the responsibility of the operating system. Never of the individual applications nor the package maintainers. A good, secure, operating system should be able to run hostile apps safely. For all its shittiness and complexity, this is something that browser developers got somewhat right.
  - elcomet 6y ago
    I don't agree with your statement. Apps can use some low-level calls to the OS, to do things that cannot be replicated in the same way in a sandbox. So it is not surprising that some parts of apps must be rewritten. If they are not rewritten, they just don't work in the sandbox. That's exactly the goal of a sandbox. Provide safe API for applications, and block apps that are trying to access more.
michaelt 6y ago
> Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions, in other words, write access to the user home directory I agree it's absurd to have a sandbox system that doesn't protect the home directory [1] Browsers and smartphones have an advantage here, because every app uses their file-open and file-save dialogs. If the user wants to open /home/user/pictures/whatever.jpg the sandboxed code gets access to that file and that file only, with the user's explicit consent. And if the app's file formats and suchlike don't match that way of working, tough luck because there's no alternative. Whereas on Linux, where there are already 6+ other ways of packaging and distributing your app, a new entrant doesn't have the power to dictate terms or force developers to change their programs. And distributing a version of Gimp that couldn't open files in the user's home directory would be absurd. [1] https://xkcd.com/1200/ https://xkcd.com/1200/
- lathiat 6y ago
  OS X managed to solve this using the standard file browser API grants access to the file. That’s a little more challenging on Linux though perhaps not impossible.
  - dylan-m 6y ago
    That's exactly how it works in Flatpak, and you get it for free if you use GTK's FileChooserNative dialog: https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserN... If your application is inside a sandbox, it communicates with another process that presents the file chooser and hands over permissions based on the user's selection. It is possible to choose directories in the same way, and portals are always improving: https://github.com/flatpak/xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal. Plenty of Flatpak applications actually do use this, but the author of this website loves to pick out the ones that don't so he can act like the project is flawed to the core and justify his sensationalist domain name. But actually it is very solvable, it is being solved, and in many cases you can tighten an application's sandbox with a two line diff.
noja 6y ago
You want the meaning of sandboxed in flatpak changed, and for it not include access to the home dir? That seems fair. But with the current UI, I think most people expect that a video player can open video files in their home directory.
- Semaphor 6y ago
  I never used a system with flatpak, but when I read sandboxed I expect the maximum permission to be read-only access to my home directory or something like android where it asks for additional permissions.
  - gommm 6y ago
    Read only is already giving the keys to the kingdom if internet connections are not limited. Any sandboxing that doesn't protect against exfiltrating private documents is not sandboxing at all. It's fine if it's a trade off between usability and security but then they shouldn't call it sandboxing or make it very clear that that's the trade off.
    - silon42 6y ago
      +1... need outgoing connections whitelisting, blocking all by default.
- jmillikin 6y ago
  For effective sandboxing you have to integrate something like capability passing and delegated access. For example, opening a file with drag-and-drop should allow access to that file, and the File > Open menu should do the sandbox equivalent of a hypercall to open a privileged file browser widget.
  - tgragnato 6y ago
    Or, make people aware they are passing files between different sandboxes. ..à la Qubes.. https://www.qubes-os.org/doc/copying-files/ https://www.qubes-os.org/doc/copying-files/
odiroot 6y ago
So, Snaps are bad, Flatpak is bad. What's good?
- pizza234 6y ago
  Spreading the PPAs culture, hoping that usage, and consequently tooling, will improve. What at least some people don't understand, is that PPAs make the source available, so one is not downloading a black box. Plus, they also add reproducibility, which is not to underestimate.
  - alanfranz 6y ago
    Do PPAs work on non-Ubuntu distributions? I thought there was one old ticket about supporting Debian, and it was ultimately closed or abandoned. Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern.
    - cies 6y ago
      > Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern. Therefor we use opensource. Anything you dont trust is even hard to run safely in a sandbox. BTW +1 for PPA culture.
      - zaarn 6y ago
        OpenSource doesn't prevent CVEs that allow attackers to take over anyway. What If you install script has a bug that lets an attacker place arbitrary SUID binaries? Or it has a bug that deletes your entire system (Steam had this bug and the script was open and available, they weren't the only ones either).
      - alanfranz 6y ago
        It's a totally different concern. I don't understand how PPAs and similar distribution approaches (i.e. native packages with hosted build systems) are getting mingled with flatpak and/or snap sandboxing objectives. You can distribute open source software via flatpak or snap. And you can create a build system that takes open source software as a source and creates a flatpak or snap distribution. It's totally possible to hide a backdoor in an open source software. A working sandbox will prevent certain attacks to your system, whether it was built from an open source or not. This already works on most (all?) mobile operating systems.
de_watcher 6y ago
Let every app haul its own libraries. Be surprised that they aren't patched and contain vulnerabilities.
- bregma 6y ago
  It's like saying we don't need vaccines any more because no one is getting sick.
  - nix23 6y ago
    If no one gets sick then you don't need vaccines.
- tutfbhuf 6y ago
  So like Docker.
  - tn890 6y ago
    At least Docker is standardized and has a growing culture of scanning images (especially base images like ubuntu,debian,alpine that everyone bases their image on). Snap/Flatpak are just an unnecessary disaster IMO.
- zaarn 6y ago
  Apps simply need a solid CI pipeline so that when dependencies have security patches, the app is automatically rebuilt and pushed out with the patches as soon as possible.
  - Avamander 6y ago
    Which negates the need for containerization...
    - zaarn 6y ago
      Well, not quite. The containerization still has advantages. For one you have a solid and predictable baseline system regardless of what distro the user installed. Next you have sandboxing (if properly applied) protecting the user until they install the update (which might be some time). You can also SXS the application in case you want to (ie some feature in the app was removed or changed but you want the new version too). Layered security is the biggest plus here though.
Iolaum 6y ago
In essense there's two main issues raised: 1. Apps still use the filesystem=host/home instead of intended portals bypassing the sandbox. 2. Common runtimes have un patched security issues. Re 1) This is a backwards compatibility option until app developers start explicitly coding for flatpak compatibility. Given the money involved (~0) I can understand why it's taking some time. As a user one can address this with flatseal[1]. RE 2) This is more a problem of the ecosystem rather than a problem of the people developing flatpak. And it's not like this problem is not often encountered in other ecosystems. This just shows that the ecosystem is still in early stages. Still it s something worth pointing out and hopefully people at freedesktop.org look into it. [1]: https://flathub.org/apps/details/com.github.tchx84.Flatseal https://flathub.org/apps/details/com.github.tchx84.Flatseal
- DarkWiiPlayer 6y ago
  > Apps still use the filesystem=host/home instead of intended portals bypassing the sandbox. The main issue seems to be the fact that flatpak still claims these apps to be "sandboxed", which is simply a lie. Properly communicating this situation to the user is all the article really asks for (and this seems very reasonable)
  - Iolaum 6y ago
    It's not flatpak, its the Gnome software center. Not the same thing. However removing the sandbox picture for apps that use the filesystem=host/home permissions on Gnome Software would be a better representation of reality.
- mapgrep 6y ago
  It seems like 2) gets to the heart of what flatpak is and how it works. The argument in favor of traditional packaging over flatpak is that security vulns in dependencies get fixed for all packages at once. The architecture of flatpak allows / encourages package maintainers to update vulnerable dependencies at their leisure. The fact that this is observed in the wild in the linked article seems a natural consequence. What is the mechanism that would cause this behavior to change as the ecosystem matures?
badsectoracula 6y ago
> But is it just this one application? Let's look at the official runtimes at the heart of Flatpak (org.freedesktop.Platform and org.gnome.Platform 3.36 - as of time of writing used by most of the applications on Flathub). This is why the idea of "runtimes" is bad at the core: existing applications do not benefit from new features and fixes in the latest version of the runtime. But fixing this means that said "runtimes" (ie Gtk, et al) need to actually give a damn about backwards compatibility, which is certainly not something anyone on the desktop side of Linux above X11 cares (and they want to break X11 too instead of fixing it because "it is too hard to fix it so let's throw everything away and make something new that for some magical reason wont also become hard to fix in the future"). Why the idea of having a standard set of libraries to handle common GUI tasks that are available "everywhere" (in desktop distros at least), just like the C library and X11 library (so far) is available everywhere and can be relied on in the long term (think decades, not weeks) is something that sounds like science fiction instead of common sense is beyond me.
- Flex247A 6y ago
  Isn't that what happens in open source projects? Different groups of people with different ideas trying to propel the project in their direction?
- xioxox 6y ago
  At least Qt cares more about compatibility: https://wiki.qt.io/Qt-Version-Compatibility https://wiki.qt.io/Qt-Version-Compatibility - Qt 5.x.y releases are supposed to be binary compatible with each other.
  - badsectoracula 6y ago
    Qt5.x.y might be compatible, but what about Qt4.x.y or Qt6.x.y? If some program is linked against Qt4.x.y it wont get any benefits and fixes from Qt5.x.y and the same will happen with Qt6.x.y. And TBH i'm not sure if a C++ library can ever be backwards compatible, at least without major major hacks (think like automatically generating a "proxy" library that uses the old ABI to forward calls to the new ABI - i think the only C++ API that ever did something like that is Haiku so that they support both G++ 2.95 from BeOS and modern G++ programs from the same libraries - even then this is easier for them since they're the OS and can decide they'll always distribute those proxy libraries, which isn't something you can rely all Linux distros to do), since C++ does not even pretend to have a stable ABI. I know that the G++ developers are trying to keep things compatible but i'm not sure of the C++ designers care that much. On the other hand on Windows, just a few hours ago i was playing a recent(ish) game made with RPG Maker 2000, which as the name implies was made two decades ago and yet still works perfectly fine. And i have a bunch of older programs that work fine linking against the latest version of Windows 10's libraries, with all the fixes and new features they've got over the years.
cheph 6y ago
Currently I happily use flatpak for Slack, Teams, Bitwarden, Spotify, Geeqie, Zotero, Inkscape and other things. The options here are: 1. Run those things directly as OS packages or sometimes AppImages or just precompiled binaries. 2. Run them via flatpak. 3. Don't run them I don't think 1 is more secure than 2, and 3 is not really something I care for. So sure, Flatpak has it's issues, however I still appreciate it and IMO it is better than snap and AppImage. I also use AppImage for some things where the sandboxing of flatpak gets in the way too much, but snap never worked for anything that I tired it with.
- factorialboy 6y ago
  Agreed. Things don't have to be perfect. They just have to be a little better than alternatives.
  - JosephRedfern 6y ago
    Things don't have to be perfect, but they need to be honest. To state that an application with full access to the host's filesystem is "sandboxed" is surely very harmful and very misleading.
    - cheph 6y ago
      It is sandboxed, sandboxed in this context just does not say anything about filesystem access. But it still says something about how it is running and again most people would exect something like gimp to have access to the host filesystem when they install it. You have options to whitelist specific directories in flatseal if you want to restrict it more.
  - boudin 6y ago
    I agree with that, flatkpak is very much work in progress. A lot of packages are still unofficial. Some software are also not meant to be sandboxed and do require access to the whole file system. I do think it is going in the right direction though. The author is also mistaking Gnome Software (the gui for managing apps in gnome that has a flatpak backend) and flatpak itself. Marking the app as Sandboxed when it's not is a gnome software issue, not flatpak.
qwerty456127 6y ago
Obviously both FlatPack and Snap have failed. Everybody hares them for many serious reasons. Yet there are awesome ideas behind. The Mac way of installing apps (by just putting the packages into a dedicated directory) is cool and intuitive, removing a lot of entities a user has to understand. Sand-boxing and being able to fine-tune the interactions with the host system and the Internet an app is allowed to perform is a feature absurd to be lacking. Do we need to invent a new format, taking FlatPack and Snap mistakes in account to just get all of that, implemented a working and easily usable way?
- gibspaulding 6y ago
  Situation: There are 14 competing standards...
  - qwerty456127 6y ago
    Obviously. Buе this principle should not be followed fanatically. In the real world there are cases when a new standard can be introduced for good and take over. You just have to thing twice before inventing a wheel - to make sure it's going to be sooooo much better that it's worth it. In this actual situation we have ther isn't going to be "14 standards" because there is no standard (for packages of this kind) so far, only a number of candidates. The first one to be good enough will become the first standard.
- 3np 6y ago
  I'm thinking that good standard practices and abstractions for SELinux and, optionally, per-application users would go a long way to solve these problems.
- Santosh83 6y ago
  No amount of inventing new formats and technologies will solve any major problem under Linux because the ecosystem is not developed by a single vendor. Any solution will not be uniformly adopted and there will be multiple competing solutions, lacking various levels of polish. Also the money under Linux is with servers, so unless that changes, the desktop landscape is never going to approach MacOS or iOS cohesiveness. Too many ideas, too many projects and efforts, too little top-level organisation and too little time or monetary interest for consumer desktop solutions, especially by the largest players who're all focused on the server and cloud and any benefit for the desktop is incidental.
compsciphd 6y ago
I strongly believe that both flatpak and docker both went about the wrong way of building images. they should have leveraged the package model that linux distributions already have and viewed them as mix and matchable layers much like packages are mix and matchable. with full dependency resolution. i.e. creating an "apache" container image should be as easy as "apt-get install apache" but without actually installing anything. just creating a manifest that references the packages/layers that are needed. simple upgrades a container image is then just upgrading the set of layers in the container image, and unlike docker where even if 2 layers are exactly the same content, if a layer "above" them is different, they are different layers, in a package -> layer concept that's unnecessary. In fact, this is what I published and created the notion of container images that are defined by a file system that is created by composing a set of shared layers together, but Docker took the easy way out and punted on that. this would also make it simple(r) to do security analysis on container images as well as compose multiple images together. https://www.usenix.org/legacy/events/atc10/tech/tech.html#Potter https://www.usenix.org/legacy/events/atc10/tech/tech.html#Po... https://www.usenix.org/legacy/events/lisa11/tech/#Potter https://www.usenix.org/legacy/events/lisa11/tech/#Potter (which also goes to my in joke that I'm the only one who can get a job that requires 10+ years of docker experience ;) )
- cheph 6y ago
  Sometimes the easy way is all that there is capacity for. So I agree there are potentially better ways but IMO the world is better off with flatpak and docker than without them and we are free to still investigate and try better ways with all the time we save with docker and flatpak. I for example use conan(.io) for some binaries - and there you can compose arbitrary packages - and theoretically it can serve as the basis for a package based approach to composition.
  - pjmlp 6y ago
    HP-UX Virtual Vault was a thing back in 1999, among other examples I can reach for. Sometimes before getting the capacity, one should learn from what already was achieved in the past.
  - 6y ago
viseztrance 6y ago
To be fair - if you make a website named flatkill you're signalling you don't want a dialog with the developers, and just expect them to throw in the towel and call it quits. Later edit - just to be clear, it's the kill part that I have a problem with. For example, name it flatrepair and developers will likely see your statements as something constructive.
rbanffy 6y ago
I never quite understand what is so broken in package managers that a solution like this or snaps was a good idea. Can someone tell me again what problems do this actually solve? Note: not being Mac-like is not an actual problem.
- f1refly 6y ago
  It's an easy solution for lazy developers. maintaining dependencies is a hassle, and with proprietary software users can't even do it themselfes if the developers decide that an 8 year old ssl lib is perfectly fine. The distributions probably won't keep that lib around either, so the easiest solution for proprietary vendors who don't care about dependency updates is to ship it all in a self contained bundle. It also makes it easier to clean up when uninstalling and makes for better damage control by limiting what can be broken if done right, but like the article said this is not what it's actually all about since noone seems to care about these points.
  - rbanffy 6y ago
    > It also makes it easier to clean up when uninstalling I think pretty much every package manager tracks what was installed manually and what was installed as a dependency of something else, so that it's easier to just remove everything that is no longer needed.
    - pxc 6y ago
      With a traditional binary package manager for Linux, if some application needs a special version of a dependency, you need to install that special version of the dependency systemwide, overriding whatever would come from your default repos. When you remove that package, you now also have to change the configuration of your repos to remove the one that it came from, or arrange a vendor change (the best case, with a powerful package manager like zypper), then run an upgrade to get the default one back into place. What the GP is talking about is how containerized packages eliminate that step during uninstallation.
      - 6y ago
jillesvangurp 6y ago
Relative to running the same application without flatpak: - You'd expect the application to run as your user and have full access to the home directory. Many applications expect to have this access. This is what it means to have user space applications. Flatpak is not about fixing or changing this. - You'd expect individual applications might have out of date dependencies. Depending on the application this might be completely fine. This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak. So, works as advertised and intended. If your flatpak install has security bugs, update it. If you use a linux distribution that ships an out of date flatpak with fixed security issues, consider using a different one or update it yourself. If you use flatpak apps from developers that can't be bothered to release updates or fix bugs, consider using something else. Basically, flatpak not being a middlemen between you and the application developers kind of is the whole point. They don't mention sandboxing on their frontpage, at all. This is not a goal. Instead, providing a cross distribution consistent installation experience is the main goal. They are not trying to be more secure than manually installing packages on your system. So, these are not security bugs as far as I can see. It's not a security nightmare. It's fine. Actually looks interesting and might give it a try if/when I get rid of my mac.
- vibrant_mclean 6y ago
  > This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak If it was a regular application installed by a linux package manager, the dependencies will be automatically updated to fix security issues(At least in most cases).
- gridlockd 6y ago
  > They don't mention sandboxing on their frontpage, at all. This is not a goal. ...and without this "fake sandboxing" strawman, flatkill.org is left without a convincing argument. The security trade-offs that come with flatpak are the same tradeoffs that desktop operating systems like MacOS and Windows have made since their inception. Considering that these are successful desktop operating systems, whereas Linux is not, one might conclude that these are the right tradeoffs, all things considered. Sure, it's "a security nightmare", but we've been living through it for decades. The alternatives clearly aren't good enough to bring everyone to move over.
mfontani 6y ago
I run apps like that inside a docker container, which is a little bit better, I think: - security library updates update with the base OS, which I update religiously and images are rebuilt (via "make") whenever the base updates, too - the apps are effectively "somewhat" sandboxed - I only bind-mount the directories I want the app to have access to (i.e. -v "$HOME/Pictures:/home/user/Pictures", -v "$HOME/.config/appname:/home/user/.config/appname" etc) While this isn't ideal for graphical apps due to needing sharing the X11 socket for things to work well, which comes with its own type of problems... ... at least no app can change _my_ bashrc, simply because it can't even see it, nevermind edit it. Going one step further, some bind mounts can also be mounted ":ro" to ensure the app cannot change the contents.
- pferde 6y ago
  I also use certain desktop programs via docker, but like you say, it isn't ideal. Not just for the X11 socket (which is a potential security issue on its own), but also for audio (both ALSA and Pulseaudio can be made to work, but you have to bind-mount correct sockets, use correct user IDs and set correct environment variables) and video (usually hw-accelerated, so you have to install correct opengl libraries for your hardware and keep them on correct versions to match the drivers your host is running. It all works, and provides some benefits (it is also fun, if you're into sysadmining!), but it kind of breaks one of the basic promises of "dockerizing" - that the containers are independent of what the host looks like. e.g. I cannot just take the Dockerfile for a video streaming app container from my desktop with a Nvidia GPU, and use it as-is on my laptop with an Intel GPU.
PaulHoule 6y ago
Why are Linux distros working so hard at finding packaging systems worse than the status quo. Usually installing a large package from a .deb file takes just a few seconds. It took a few minutes to install chromium from a snap. It's faster to install programs on Windows. What's up people?
- jhasse 6y ago
  > Why are Linux distros working so hard at finding packaging systems worse than the status quo. Not everything flatpak does is worse than the status quo. Whether it's worse all things considered is debatable.
  - PaulHoule 6y ago
    Having two installation systems is automatically worse than having one -- unless there are LARGE advantages to having the second one. For instance, once you have two places a software package has come from you've added the cognitive load in debugging to determine where a given package came from.
    - jhasse 6y ago
      You just mentioned another of flatpak's disadvantages. > [...] unless there are LARGE advantages to having the second one. That's the thing: What's considered a "LARGE advantage" is highly subjective. Not something you can really quantify.
- maple3142 6y ago
  Because some developer wants a easier way to distribute their software instead of packaging the software in multiple format or wait for distribution maintainer to update? Also, some user also wants to get the latest software too.
mongol 6y ago
Who is this anonymous author who made effort to set up a specific website just to rant about Flatpak shortcomings? Seems strange to me.
skohan 6y ago
Is there a positive case for flatpack? I have only ever heard people basically cursing its existence.
HashingtheCode 6y ago
Here is a comparison between Flatpak, Snaps and Appimage. Notice in the table regarding sandboxing. Someone is telling porky lies here. https://www.fosslinux.com/42410/snap-vs-flatpak-vs-appimage-know-the-differences-which-is-better.htm https://www.fosslinux.com/42410/snap-vs-flatpak-vs-appimage-...
dylan-m 6y ago
In this week's story of bad open source contributions[1], we bring you some dude who keeps paying for a domain and spending wads of time writing long and poorly targeted diatribes against one of the only genuine efforts to actually address the thing he purports to care about. Instead of filing bug reports, or writing code, or advocating for the thing that he wants? Or at least engaging in the bare minimum effort to assign blame correctly. - The fact that GNOME Software says things are "Sandboxed" without further information is (gasp) a GNOME Software issue. And I don't think anyone is all that happy about it. In fact, there's a redesign pending, but resources are limited. GNOME Software is a rickety old beast and needs love, but it would be nice if people weren't trying to tear down surrounding projects as a result? - Good job finding a security vulnerability. Please report an issue with the gitg Flathub repo[2], and with freedesktop-sdk[3], respectively. Congratulations on your amazing contribution! Have a free t-shirt before they run out [4]. - Speaking of Flathub, there is a discussion to be had about Flathub's lackadaisical approach around submitting stuff (and updating it). Maybe write about that? Or, better yet, don't write about how it's terrible and kills babies: write about how we can solve this stuff. For example, we could add some better backend tooling for Flathub that checks for unpatched libraries. Flatpak makes this sort of thing pretty doable. The Flatkill guy seems to have some experience with that, so, maybe that can be his next contribution (after he reports those two issues in their respective bug trackers). Heck, "Flatkill" is an okay name for a vulnerability scanner, so we're halfway there. - To clarify, it's okay giving these things shit in your spare time, but once you're running a domain and spreading fear and uncertainty for dubious reasons (when being constructive is actually less effort), you're just being an asshole. [1] https://news.ycombinator.com/item?id=24658052 https://news.ycombinator.com/item?id=24658052 [2] https://github.com/flathub/org.gnome.gitg/issues https://github.com/flathub/org.gnome.gitg/issues [3] https://gitlab.com/freedesktop-sdk/freedesktop-sdk https://gitlab.com/freedesktop-sdk/freedesktop-sdk [4] https://hacktoberfest.digitalocean.com/ https://hacktoberfest.digitalocean.com/
- bepvte 6y ago
  I really wonder what the author of the sites endgoal is. Do they want flatpak to be eliminated? Do they think theyre stopping the next "systemd" from taking over their favorite distro?
craftinator 6y ago
All that, and they are still WILDLY better than Snaps. You chose poorly, Canonical.
dang 6y ago
The previous threads are https://news.ycombinator.com/item?id=23520603 https://news.ycombinator.com/item?id=23520603 (3 months ago) https://news.ycombinator.com/item?id=18180017 https://news.ycombinator.com/item?id=18180017 (2018)
mcovey 6y ago
Linux packaging certainly is a mess. I have 50+ "update-foo" scripts for programs that want me to use yet another package manager. Everything that doesn't use apt is in there, so many of them just run "pip install foo" or "npm install foo", at least this way I don't have to remember which program uses which package manager. I used to be very adamant that if something did not have an apt repository then I wouldn't use it, but that's become hard to do. Even the piece of software I use the most, my browser, is not managed by apt. Firefox (developer edition) lives in ~/.local/lib and updates itself.

377 points by krimeo 6y ago

My issues with the post start with the tone. It's not a respectful tone, rather aggressive and always flashes me back to people who write similar blogposts about systemd or something else that is new but not accepted by greybeards yet. Fonts and theming are an issue, I agree, however, this isn't entirely the fault of the flatpak maintainers but in part the fault of a fragmented and hard-to-compose linux ecosystem when it comes to their configuration. The IME issue is a problem but I don't think a dynamically linked system would benefit much here. The solution is to make portals between flatpak and the system more extensible and versioned, so that an outside daemon an talk to flatpak apps and potentially flatpak could even try to determine which runtime to use based on what outside portal versions are available.

simias 6y ago
I skimmed the article and I don't find the tone super disrespectful. No ad-hominem, no insults to the developers etc... The backlash against systemd was unacceptable because it ended up targeting people and not the technology. Writing an init system shouldn't net you death threats. Beyond this, and not unlike systemd, flatpak has been pushed hard down people's throat by powerful entities within the ecosystem, so it's not surprising that in both cases there has been some intense backlash. I also personally think that in both cases it's warranted.
- shrewduser 6y ago
  I agree, how thin skinned are people? this seems like valid criticism that wasn't acted on in two years. What is an appropriate 'tone' in this case
  - chekovcodes 6y ago
    Tone is narcissistic and self-important - it does not even tip a hat to address prioritisation or resource constraints - it's just "this is important to me THEREFORE IT IS IMPORTANT, GNASH, WAIL". I also think the author does not understand end-user software - if you package everything up so it is very secure by default, almost nobody will ever use it and nobody will care except the people who are capable of securing it themselves.
  - cycloptic 6y ago
    An appropriate tone would be to press the angle that help is needed and either offer to help patch the applications or mention where contributors can get started. I get the author's concern but there is nothing useful in this article. It's misleading suggesting that the problem is with flatpak when the problem is that certain applications aren't using its full capabilities, aren't configured correctly and are in need patching. Or in the worst case, might need a redesign to fit the sandboxing model. This needs to happen with any sandbox that uses this model, not just flatpak. There is nothing else that can be done about this short of suggesting users switch to a different sandboxing model like Qubes. (Maybe the blog author can try that too and see how it goes, or could develop their own sandboxing model just to see how hard it is on a complex system like Linux)
    - dylan-m 6y ago
      As well as misleading, the article seems outdated? Which is weird, because archive.org's first snapshot of it is today. So, GNOME Software has included a "Permissions" field (which lists an application's specific sandbox holes) since - if I recall correctly - GNOME 3.34: https://i.imgur.com/lCGgA1B.png https://i.imgur.com/lCGgA1B.png. Not perfect, but definitely better than pictured. It's a bit of a shame that people have to use older versions of GNOME in 2020, but then, it's nice that Flatpak makes it easy to run new applications regardless :) Also, I was trying to verify the author's claim about a vulnerable libssh in the gitg package, partly because I was curious whether they'd bothered to report any of these issues upstream. Looks like that was fixed in May: https://github.com/flathub/org.gnome.gitg/pull/12 https://github.com/flathub/org.gnome.gitg/pull/12. Similar story with ffmpeg: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/d7d8582f750e1165fd3fd637f8fcb62104ede2c8 https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/.... So, woefully behind schedule, but, how long was the author sitting on these? It would be more accurate, less irritating, and more persuasive if they simply talked about it after the fact: this happened, various things are wrong with it, it should be avoidable, etc.
      - frabbit 6y ago
        The first two CVEs linked in the article do not even exist: whether due to rejection or something else is uncertain.
- matthiasv 6y ago
  > Beyond this, and not unlike systemd, flatpak has been pushed hard down people's throat by powerful entities within the ecosystem, [...] Sounds like a tinfoil hat theory to me. Powerful entities? Pushed down people's throat? You are free to ignore Flatpak, no one is forcing it on anyone.
turbinerneiter 6y ago
It's hard to keep a civil tone if you feel like the world around you is descending into madness, and this is exactly what the authors of this posts feel. Its hard to have a civil discussion if everyone pulls into a direction you deem wrong and your words are never convincing anyone. I have similar resentments when people in my company push for docker on embedded systems, because they are used to docker on the server, and whenever I ask them which problem they are solving on the embedded system with docker, they describe things that are wrong. I don't share the authors strength of opinion on flatpak, although I see the same issues, and I don't want to advertise or excuse strong "tone" - but I understand the frustration.
- pjc50 6y ago
  > push for docker on embedded systems Aaargh! A particularly odd one as most embedded systems are handled as "images" of some sort - firmware blobs, ramdiscs, imaged HDDs for embedded PCs and so on.
- kanox 6y ago
  What exactly is wrong with docker on embedded systems? Many have the memory and storage to afford containers and existing established distros like yocto are not very good. I'd much rather deal with Dockerfiles than buildbake.
  - turbinerneiter 6y ago
    What is the problem docker solves?
  - Obsnold 6y ago
    Just to clarify yocto is not a distro but a project that allows you to create your own custom distro. Two yocto builds could be completely different from one another even using different package managers.
    - kanox 6y ago
      Yocto and various derivatives can be used to "build software" in the same way that Dockerfiles can be used to "build software" but using yocto is a much worse experience.
ylyn 6y ago
I don't see an issue with the tone. Actually, why are people so concerned about tone nowadays? It matters, but this is perfectly fine. I feel like you can't find anything to nitpick about the post, so you pick on the tone instead.
- zaarn 6y ago
  I've brought up issues beside tone because of this. In case those aren't enough; I think the issues brought up aren't issues with flatpak. The first issue is with a GUI application on top of flatpak and the second is a packaging issue of the runtimes. These aren't inherently problems with flatpak so I mentally don't count them.
  - steerablesafe 6y ago
    Don't forget lying about sandboxing.
    - dylan-m 6y ago
      Yeah, that's a dubious claim as well. Here is how GNOME Software presents a sandboxed application: https://i.imgur.com/VMsj6mk.png https://i.imgur.com/VMsj6mk.png Is it a bad interface? Sure. Is the list of permissions hard to find? Hell yes. Is the Sandboxed emblem kind of misleading? Yeah. But here (in at least GNOME Software 3.36) you see a list of the relevant permissions available to the application. Nobody is lying here. For contrast, here is an application with a stricter sandbox: https://i.imgur.com/lCGgA1B.png https://i.imgur.com/lCGgA1B.png The point here is both of these are sandboxed. Each sandbox just has particular holes in it. For GNU Octave, more than seems appropriate. Users misunderstand that in the same way people misunderstand "autopilot" and that's a good issue to bring up, but then I don't think non-technical users understand what "sandboxed" means anyway and technical users should be able to take one more gorramn step and learn that "sandboxed" obviously comes with particular limitations [at least in the present day] or it isn't going to do anything.
sergeykish 6y ago
You've skipped CVE. Flatpak has a lot of claims [1], author feels them as a lie. And he provides facts in support. Linux "next generation technology" would certainly alert users of insecure application. This does not. The story of themes and dbus shows how hard it is to contain all dependencies. Also there were a lot of claims here that Linux distributions makes no good, static linking is better and libraries would be patched. Now lets switch perspective. Windows users are perfectly fine running closed source software which may contain outdated dependencies. Most of them are not updated anyway. And it has gallery, something Winget still lacks. Looks like next gen. What is cry for open source developer may be fine for consumer. Personally I'm fine with Flatpak, Appimage. There should be some way to install proprietary software. And some starting point to make it safe. [1] https://flatpak.org/ https://flatpak.org/

akerro 6y ago

If I understand correctly, a lot of desktop apps need to rewrite their parts of code to adopt to flatpak, and probably also snap to use the sandbox correctly. This post is therefor not criticizing flatpak but GNU Octave for not having enough dev power to implement it.

enriquto 6y ago
> a lot of desktop apps need to rewrite their parts of code (...) to use the sandbox correctly. This is completely backwards. Security features and encapsulation are the responsibility of the operating system. Never of the individual applications nor the package maintainers. A good, secure, operating system should be able to run hostile apps safely. For all its shittiness and complexity, this is something that browser developers got somewhat right.
- elcomet 6y ago
  I don't agree with your statement. Apps can use some low-level calls to the OS, to do things that cannot be replicated in the same way in a sandbox. So it is not surprising that some parts of apps must be rewritten. If they are not rewritten, they just don't work in the sandbox. That's exactly the goal of a sandbox. Provide safe API for applications, and block apps that are trying to access more.

michaelt 6y ago

> Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions, in other words, write access to the user home directory I agree it's absurd to have a sandbox system that doesn't protect the home directory [1] Browsers and smartphones have an advantage here, because every app uses their file-open and file-save dialogs. If the user wants to open /home/user/pictures/whatever.jpg the sandboxed code gets access to that file and that file only, with the user's explicit consent. And if the app's file formats and suchlike don't match that way of working, tough luck because there's no alternative. Whereas on Linux, where there are already 6+ other ways of packaging and distributing your app, a new entrant doesn't have the power to dictate terms or force developers to change their programs. And distributing a version of Gimp that couldn't open files in the user's home directory would be absurd. [1] https://xkcd.com/1200/ https://xkcd.com/1200/

lathiat 6y ago
OS X managed to solve this using the standard file browser API grants access to the file. That’s a little more challenging on Linux though perhaps not impossible.
- dylan-m 6y ago
  That's exactly how it works in Flatpak, and you get it for free if you use GTK's FileChooserNative dialog: https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserN... If your application is inside a sandbox, it communicates with another process that presents the file chooser and hands over permissions based on the user's selection. It is possible to choose directories in the same way, and portals are always improving: https://github.com/flatpak/xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal. Plenty of Flatpak applications actually do use this, but the author of this website loves to pick out the ones that don't so he can act like the project is flawed to the core and justify his sensationalist domain name. But actually it is very solvable, it is being solved, and in many cases you can tighten an application's sandbox with a two line diff.

noja 6y ago

You want the meaning of sandboxed in flatpak changed, and for it not include access to the home dir? That seems fair. But with the current UI, I think most people expect that a video player can open video files in their home directory.

Semaphor 6y ago
I never used a system with flatpak, but when I read sandboxed I expect the maximum permission to be read-only access to my home directory or something like android where it asks for additional permissions.
- gommm 6y ago
  Read only is already giving the keys to the kingdom if internet connections are not limited. Any sandboxing that doesn't protect against exfiltrating private documents is not sandboxing at all. It's fine if it's a trade off between usability and security but then they shouldn't call it sandboxing or make it very clear that that's the trade off.
  - silon42 6y ago
    +1... need outgoing connections whitelisting, blocking all by default.
jmillikin 6y ago
For effective sandboxing you have to integrate something like capability passing and delegated access. For example, opening a file with drag-and-drop should allow access to that file, and the File > Open menu should do the sandbox equivalent of a hypercall to open a privileged file browser widget.
- tgragnato 6y ago
  Or, make people aware they are passing files between different sandboxes. ..à la Qubes.. https://www.qubes-os.org/doc/copying-files/ https://www.qubes-os.org/doc/copying-files/

odiroot 6y ago

So, Snaps are bad, Flatpak is bad. What's good?

pizza234 6y ago
Spreading the PPAs culture, hoping that usage, and consequently tooling, will improve. What at least some people don't understand, is that PPAs make the source available, so one is not downloading a black box. Plus, they also add reproducibility, which is not to underestimate.
- alanfranz 6y ago
  Do PPAs work on non-Ubuntu distributions? I thought there was one old ticket about supporting Debian, and it was ultimately closed or abandoned. Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern.
  - cies 6y ago
    > Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern. Therefor we use opensource. Anything you dont trust is even hard to run safely in a sandbox. BTW +1 for PPA culture.
    - zaarn 6y ago
      OpenSource doesn't prevent CVEs that allow attackers to take over anyway. What If you install script has a bug that lets an attacker place arbitrary SUID binaries? Or it has a bug that deletes your entire system (Steam had this bug and the script was open and available, they weren't the only ones either).
    - alanfranz 6y ago
      It's a totally different concern. I don't understand how PPAs and similar distribution approaches (i.e. native packages with hosted build systems) are getting mingled with flatpak and/or snap sandboxing objectives. You can distribute open source software via flatpak or snap. And you can create a build system that takes open source software as a source and creates a flatpak or snap distribution. It's totally possible to hide a backdoor in an open source software. A working sandbox will prevent certain attacks to your system, whether it was built from an open source or not. This already works on most (all?) mobile operating systems.

de_watcher 6y ago

Let every app haul its own libraries. Be surprised that they aren't patched and contain vulnerabilities.

bregma 6y ago
It's like saying we don't need vaccines any more because no one is getting sick.
- nix23 6y ago
  If no one gets sick then you don't need vaccines.
tutfbhuf 6y ago
So like Docker.
- tn890 6y ago
  At least Docker is standardized and has a growing culture of scanning images (especially base images like ubuntu,debian,alpine that everyone bases their image on). Snap/Flatpak are just an unnecessary disaster IMO.
zaarn 6y ago
Apps simply need a solid CI pipeline so that when dependencies have security patches, the app is automatically rebuilt and pushed out with the patches as soon as possible.
- Avamander 6y ago
  Which negates the need for containerization...
  - zaarn 6y ago
    Well, not quite. The containerization still has advantages. For one you have a solid and predictable baseline system regardless of what distro the user installed. Next you have sandboxing (if properly applied) protecting the user until they install the update (which might be some time). You can also SXS the application in case you want to (ie some feature in the app was removed or changed but you want the new version too). Layered security is the biggest plus here though.

Iolaum 6y ago

In essense there's two main issues raised: 1. Apps still use the filesystem=host/home instead of intended portals bypassing the sandbox. 2. Common runtimes have un patched security issues. Re 1) This is a backwards compatibility option until app developers start explicitly coding for flatpak compatibility. Given the money involved (~0) I can understand why it's taking some time. As a user one can address this with flatseal[1]. RE 2) This is more a problem of the ecosystem rather than a problem of the people developing flatpak. And it's not like this problem is not often encountered in other ecosystems. This just shows that the ecosystem is still in early stages. Still it s something worth pointing out and hopefully people at freedesktop.org look into it. [1]: https://flathub.org/apps/details/com.github.tchx84.Flatseal https://flathub.org/apps/details/com.github.tchx84.Flatseal

DarkWiiPlayer 6y ago
> Apps still use the filesystem=host/home instead of intended portals bypassing the sandbox. The main issue seems to be the fact that flatpak still claims these apps to be "sandboxed", which is simply a lie. Properly communicating this situation to the user is all the article really asks for (and this seems very reasonable)
- Iolaum 6y ago
  It's not flatpak, its the Gnome software center. Not the same thing. However removing the sandbox picture for apps that use the filesystem=host/home permissions on Gnome Software would be a better representation of reality.
mapgrep 6y ago
It seems like 2) gets to the heart of what flatpak is and how it works. The argument in favor of traditional packaging over flatpak is that security vulns in dependencies get fixed for all packages at once. The architecture of flatpak allows / encourages package maintainers to update vulnerable dependencies at their leisure. The fact that this is observed in the wild in the linked article seems a natural consequence. What is the mechanism that would cause this behavior to change as the ecosystem matures?

badsectoracula 6y ago

> But is it just this one application? Let's look at the official runtimes at the heart of Flatpak (org.freedesktop.Platform and org.gnome.Platform 3.36 - as of time of writing used by most of the applications on Flathub). This is why the idea of "runtimes" is bad at the core: existing applications do not benefit from new features and fixes in the latest version of the runtime. But fixing this means that said "runtimes" (ie Gtk, et al) need to actually give a damn about backwards compatibility, which is certainly not something anyone on the desktop side of Linux above X11 cares (and they want to break X11 too instead of fixing it because "it is too hard to fix it so let's throw everything away and make something new that for some magical reason wont also become hard to fix in the future"). Why the idea of having a standard set of libraries to handle common GUI tasks that are available "everywhere" (in desktop distros at least), just like the C library and X11 library (so far) is available everywhere and can be relied on in the long term (think decades, not weeks) is something that sounds like science fiction instead of common sense is beyond me.

Flex247A 6y ago
Isn't that what happens in open source projects? Different groups of people with different ideas trying to propel the project in their direction?
xioxox 6y ago
At least Qt cares more about compatibility: https://wiki.qt.io/Qt-Version-Compatibility https://wiki.qt.io/Qt-Version-Compatibility - Qt 5.x.y releases are supposed to be binary compatible with each other.
- badsectoracula 6y ago
  Qt5.x.y might be compatible, but what about Qt4.x.y or Qt6.x.y? If some program is linked against Qt4.x.y it wont get any benefits and fixes from Qt5.x.y and the same will happen with Qt6.x.y. And TBH i'm not sure if a C++ library can ever be backwards compatible, at least without major major hacks (think like automatically generating a "proxy" library that uses the old ABI to forward calls to the new ABI - i think the only C++ API that ever did something like that is Haiku so that they support both G++ 2.95 from BeOS and modern G++ programs from the same libraries - even then this is easier for them since they're the OS and can decide they'll always distribute those proxy libraries, which isn't something you can rely all Linux distros to do), since C++ does not even pretend to have a stable ABI. I know that the G++ developers are trying to keep things compatible but i'm not sure of the C++ designers care that much. On the other hand on Windows, just a few hours ago i was playing a recent(ish) game made with RPG Maker 2000, which as the name implies was made two decades ago and yet still works perfectly fine. And i have a bunch of older programs that work fine linking against the latest version of Windows 10's libraries, with all the fixes and new features they've got over the years.

cheph 6y ago

Currently I happily use flatpak for Slack, Teams, Bitwarden, Spotify, Geeqie, Zotero, Inkscape and other things. The options here are: 1. Run those things directly as OS packages or sometimes AppImages or just precompiled binaries. 2. Run them via flatpak. 3. Don't run them I don't think 1 is more secure than 2, and 3 is not really something I care for. So sure, Flatpak has it's issues, however I still appreciate it and IMO it is better than snap and AppImage. I also use AppImage for some things where the sandboxing of flatpak gets in the way too much, but snap never worked for anything that I tired it with.

factorialboy 6y ago
Agreed. Things don't have to be perfect. They just have to be a little better than alternatives.
- JosephRedfern 6y ago
  Things don't have to be perfect, but they need to be honest. To state that an application with full access to the host's filesystem is "sandboxed" is surely very harmful and very misleading.
  - cheph 6y ago
    It is sandboxed, sandboxed in this context just does not say anything about filesystem access. But it still says something about how it is running and again most people would exect something like gimp to have access to the host filesystem when they install it. You have options to whitelist specific directories in flatseal if you want to restrict it more.
- boudin 6y ago
  I agree with that, flatkpak is very much work in progress. A lot of packages are still unofficial. Some software are also not meant to be sandboxed and do require access to the whole file system. I do think it is going in the right direction though. The author is also mistaking Gnome Software (the gui for managing apps in gnome that has a flatpak backend) and flatpak itself. Marking the app as Sandboxed when it's not is a gnome software issue, not flatpak.

qwerty456127 6y ago

Obviously both FlatPack and Snap have failed. Everybody hares them for many serious reasons. Yet there are awesome ideas behind. The Mac way of installing apps (by just putting the packages into a dedicated directory) is cool and intuitive, removing a lot of entities a user has to understand. Sand-boxing and being able to fine-tune the interactions with the host system and the Internet an app is allowed to perform is a feature absurd to be lacking. Do we need to invent a new format, taking FlatPack and Snap mistakes in account to just get all of that, implemented a working and easily usable way?

gibspaulding 6y ago
Situation: There are 14 competing standards...
- qwerty456127 6y ago
  Obviously. Buе this principle should not be followed fanatically. In the real world there are cases when a new standard can be introduced for good and take over. You just have to thing twice before inventing a wheel - to make sure it's going to be sooooo much better that it's worth it. In this actual situation we have ther isn't going to be "14 standards" because there is no standard (for packages of this kind) so far, only a number of candidates. The first one to be good enough will become the first standard.
3np 6y ago
I'm thinking that good standard practices and abstractions for SELinux and, optionally, per-application users would go a long way to solve these problems.
Santosh83 6y ago
No amount of inventing new formats and technologies will solve any major problem under Linux because the ecosystem is not developed by a single vendor. Any solution will not be uniformly adopted and there will be multiple competing solutions, lacking various levels of polish. Also the money under Linux is with servers, so unless that changes, the desktop landscape is never going to approach MacOS or iOS cohesiveness. Too many ideas, too many projects and efforts, too little top-level organisation and too little time or monetary interest for consumer desktop solutions, especially by the largest players who're all focused on the server and cloud and any benefit for the desktop is incidental.

compsciphd 6y ago

I strongly believe that both flatpak and docker both went about the wrong way of building images. they should have leveraged the package model that linux distributions already have and viewed them as mix and matchable layers much like packages are mix and matchable. with full dependency resolution. i.e. creating an "apache" container image should be as easy as "apt-get install apache" but without actually installing anything. just creating a manifest that references the packages/layers that are needed. simple upgrades a container image is then just upgrading the set of layers in the container image, and unlike docker where even if 2 layers are exactly the same content, if a layer "above" them is different, they are different layers, in a package -> layer concept that's unnecessary. In fact, this is what I published and created the notion of container images that are defined by a file system that is created by composing a set of shared layers together, but Docker took the easy way out and punted on that. this would also make it simple(r) to do security analysis on container images as well as compose multiple images together. https://www.usenix.org/legacy/events/atc10/tech/tech.html#Potter https://www.usenix.org/legacy/events/atc10/tech/tech.html#Po... https://www.usenix.org/legacy/events/lisa11/tech/#Potter https://www.usenix.org/legacy/events/lisa11/tech/#Potter (which also goes to my in joke that I'm the only one who can get a job that requires 10+ years of docker experience ;) )

cheph 6y ago
Sometimes the easy way is all that there is capacity for. So I agree there are potentially better ways but IMO the world is better off with flatpak and docker than without them and we are free to still investigate and try better ways with all the time we save with docker and flatpak. I for example use conan(.io) for some binaries - and there you can compose arbitrary packages - and theoretically it can serve as the basis for a package based approach to composition.
- pjmlp 6y ago
  HP-UX Virtual Vault was a thing back in 1999, among other examples I can reach for. Sometimes before getting the capacity, one should learn from what already was achieved in the past.
- 6y ago

viseztrance 6y ago

To be fair - if you make a website named flatkill you're signalling you don't want a dialog with the developers, and just expect them to throw in the towel and call it quits. Later edit - just to be clear, it's the kill part that I have a problem with. For example, name it flatrepair and developers will likely see your statements as something constructive.

rbanffy 6y ago

I never quite understand what is so broken in package managers that a solution like this or snaps was a good idea. Can someone tell me again what problems do this actually solve? Note: not being Mac-like is not an actual problem.

f1refly 6y ago
It's an easy solution for lazy developers. maintaining dependencies is a hassle, and with proprietary software users can't even do it themselfes if the developers decide that an 8 year old ssl lib is perfectly fine. The distributions probably won't keep that lib around either, so the easiest solution for proprietary vendors who don't care about dependency updates is to ship it all in a self contained bundle. It also makes it easier to clean up when uninstalling and makes for better damage control by limiting what can be broken if done right, but like the article said this is not what it's actually all about since noone seems to care about these points.
- rbanffy 6y ago
  > It also makes it easier to clean up when uninstalling I think pretty much every package manager tracks what was installed manually and what was installed as a dependency of something else, so that it's easier to just remove everything that is no longer needed.
  - pxc 6y ago
    With a traditional binary package manager for Linux, if some application needs a special version of a dependency, you need to install that special version of the dependency systemwide, overriding whatever would come from your default repos. When you remove that package, you now also have to change the configuration of your repos to remove the one that it came from, or arrange a vendor change (the best case, with a powerful package manager like zypper), then run an upgrade to get the default one back into place. What the GP is talking about is how containerized packages eliminate that step during uninstallation.
    - 6y ago

jillesvangurp 6y ago

Relative to running the same application without flatpak: - You'd expect the application to run as your user and have full access to the home directory. Many applications expect to have this access. This is what it means to have user space applications. Flatpak is not about fixing or changing this. - You'd expect individual applications might have out of date dependencies. Depending on the application this might be completely fine. This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak. So, works as advertised and intended. If your flatpak install has security bugs, update it. If you use a linux distribution that ships an out of date flatpak with fixed security issues, consider using a different one or update it yourself. If you use flatpak apps from developers that can't be bothered to release updates or fix bugs, consider using something else. Basically, flatpak not being a middlemen between you and the application developers kind of is the whole point. They don't mention sandboxing on their frontpage, at all. This is not a goal. Instead, providing a cross distribution consistent installation experience is the main goal. They are not trying to be more secure than manually installing packages on your system. So, these are not security bugs as far as I can see. It's not a security nightmare. It's fine. Actually looks interesting and might give it a try if/when I get rid of my mac.

vibrant_mclean 6y ago
> This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak If it was a regular application installed by a linux package manager, the dependencies will be automatically updated to fix security issues(At least in most cases).
gridlockd 6y ago
> They don't mention sandboxing on their frontpage, at all. This is not a goal. ...and without this "fake sandboxing" strawman, flatkill.org is left without a convincing argument. The security trade-offs that come with flatpak are the same tradeoffs that desktop operating systems like MacOS and Windows have made since their inception. Considering that these are successful desktop operating systems, whereas Linux is not, one might conclude that these are the right tradeoffs, all things considered. Sure, it's "a security nightmare", but we've been living through it for decades. The alternatives clearly aren't good enough to bring everyone to move over.

mfontani 6y ago

I run apps like that inside a docker container, which is a little bit better, I think: - security library updates update with the base OS, which I update religiously and images are rebuilt (via "make") whenever the base updates, too - the apps are effectively "somewhat" sandboxed - I only bind-mount the directories I want the app to have access to (i.e. -v "$HOME/Pictures:/home/user/Pictures", -v "$HOME/.config/appname:/home/user/.config/appname" etc) While this isn't ideal for graphical apps due to needing sharing the X11 socket for things to work well, which comes with its own type of problems... ... at least no app can change _my_ bashrc, simply because it can't even see it, nevermind edit it. Going one step further, some bind mounts can also be mounted ":ro" to ensure the app cannot change the contents.

pferde 6y ago
I also use certain desktop programs via docker, but like you say, it isn't ideal. Not just for the X11 socket (which is a potential security issue on its own), but also for audio (both ALSA and Pulseaudio can be made to work, but you have to bind-mount correct sockets, use correct user IDs and set correct environment variables) and video (usually hw-accelerated, so you have to install correct opengl libraries for your hardware and keep them on correct versions to match the drivers your host is running. It all works, and provides some benefits (it is also fun, if you're into sysadmining!), but it kind of breaks one of the basic promises of "dockerizing" - that the containers are independent of what the host looks like. e.g. I cannot just take the Dockerfile for a video streaming app container from my desktop with a Nvidia GPU, and use it as-is on my laptop with an Intel GPU.

PaulHoule 6y ago

Why are Linux distros working so hard at finding packaging systems worse than the status quo. Usually installing a large package from a .deb file takes just a few seconds. It took a few minutes to install chromium from a snap. It's faster to install programs on Windows. What's up people?

jhasse 6y ago
> Why are Linux distros working so hard at finding packaging systems worse than the status quo. Not everything flatpak does is worse than the status quo. Whether it's worse all things considered is debatable.
- PaulHoule 6y ago
  Having two installation systems is automatically worse than having one -- unless there are LARGE advantages to having the second one. For instance, once you have two places a software package has come from you've added the cognitive load in debugging to determine where a given package came from.
  - jhasse 6y ago
    You just mentioned another of flatpak's disadvantages. > [...] unless there are LARGE advantages to having the second one. That's the thing: What's considered a "LARGE advantage" is highly subjective. Not something you can really quantify.
maple3142 6y ago
Because some developer wants a easier way to distribute their software instead of packaging the software in multiple format or wait for distribution maintainer to update? Also, some user also wants to get the latest software too.

mongol 6y ago

Who is this anonymous author who made effort to set up a specific website just to rant about Flatpak shortcomings? Seems strange to me.

skohan 6y ago

Is there a positive case for flatpack? I have only ever heard people basically cursing its existence.

HashingtheCode 6y ago

Here is a comparison between Flatpak, Snaps and Appimage. Notice in the table regarding sandboxing. Someone is telling porky lies here. https://www.fosslinux.com/42410/snap-vs-flatpak-vs-appimage-know-the-differences-which-is-better.htm https://www.fosslinux.com/42410/snap-vs-flatpak-vs-appimage-...

dylan-m 6y ago

In this week's story of bad open source contributions[1], we bring you some dude who keeps paying for a domain and spending wads of time writing long and poorly targeted diatribes against one of the only genuine efforts to actually address the thing he purports to care about. Instead of filing bug reports, or writing code, or advocating for the thing that he wants? Or at least engaging in the bare minimum effort to assign blame correctly. - The fact that GNOME Software says things are "Sandboxed" without further information is (gasp) a GNOME Software issue. And I don't think anyone is all that happy about it. In fact, there's a redesign pending, but resources are limited. GNOME Software is a rickety old beast and needs love, but it would be nice if people weren't trying to tear down surrounding projects as a result? - Good job finding a security vulnerability. Please report an issue with the gitg Flathub repo[2], and with freedesktop-sdk[3], respectively. Congratulations on your amazing contribution! Have a free t-shirt before they run out [4]. - Speaking of Flathub, there is a discussion to be had about Flathub's lackadaisical approach around submitting stuff (and updating it). Maybe write about that? Or, better yet, don't write about how it's terrible and kills babies: write about how we can solve this stuff. For example, we could add some better backend tooling for Flathub that checks for unpatched libraries. Flatpak makes this sort of thing pretty doable. The Flatkill guy seems to have some experience with that, so, maybe that can be his next contribution (after he reports those two issues in their respective bug trackers). Heck, "Flatkill" is an okay name for a vulnerability scanner, so we're halfway there. - To clarify, it's okay giving these things shit in your spare time, but once you're running a domain and spreading fear and uncertainty for dubious reasons (when being constructive is actually less effort), you're just being an asshole. [1] https://news.ycombinator.com/item?id=24658052 https://news.ycombinator.com/item?id=24658052 [2] https://github.com/flathub/org.gnome.gitg/issues https://github.com/flathub/org.gnome.gitg/issues [3] https://gitlab.com/freedesktop-sdk/freedesktop-sdk https://gitlab.com/freedesktop-sdk/freedesktop-sdk [4] https://hacktoberfest.digitalocean.com/ https://hacktoberfest.digitalocean.com/

bepvte 6y ago
I really wonder what the author of the sites endgoal is. Do they want flatpak to be eliminated? Do they think theyre stopping the next "systemd" from taking over their favorite distro?

craftinator 6y ago

All that, and they are still WILDLY better than Snaps. You chose poorly, Canonical.

dang 6y ago

The previous threads are https://news.ycombinator.com/item?id=23520603 https://news.ycombinator.com/item?id=23520603 (3 months ago) https://news.ycombinator.com/item?id=18180017 https://news.ycombinator.com/item?id=18180017 (2018)

mcovey 6y ago

Linux packaging certainly is a mess. I have 50+ "update-foo" scripts for programs that want me to use yet another package manager. Everything that doesn't use apt is in there, so many of them just run "pip install foo" or "npm install foo", at least this way I don't have to remember which program uses which package manager. I used to be very adamant that if something did not have an apt repository then I wouldn't use it, but that's become hard to do. Even the piece of software I use the most, my browser, is not managed by apt. Firefox (developer edition) lives in ~/.local/lib and updates itself.