1. 22
  1.  

  2. 15

    Flatkill link for convenience: https://flatkill.org/

    2020 update: https://flatkill.org/2020/

    Unsurprisingly, this “response” glosses over most of it. Particularly, flatkill seems to (justifiably) put large emphasis on the problem of the UI for flatpak promoting a false sense of security, which the response seems to ignore.

    1. 2

      It does address this

      Fortunately, this problem has been solved in recent updates. If this problem persisted, I would have criticized it too: https://theevilskeleton.frama.io/images/Flatpak-response-GNOME-Software.png

      1. 1

        A glance tells me the UI is still terribly misleading.

        Note blue background on “sandboxed”, and note details on the right side are on a bubble, thus not normally shown unless specific action (mouseover?).

        It should blink red/orange while sounding a siren… but if it did that, people would realize Flatpak is not so good and would not use it. Thus the misleading UI.

    2. 14

      […] if you think an application has permissions that are too permissive, i.e. the application can do more than you want, you can use flatpak override or Flatseal to harden the desired application.

      Why would this matter if I’ve run the application at least once already? If I carelessly download an application which has malicious code in it and execute it, it’s already over.

      It is crucial for an IDE to have access to home or host filesystems, for Git repositories, and for other external uses, otherwise it is not very useful.

      Yes, they’re Integrated Development Environments, which is why they should be Integrated, not in a sandboxed container with its own convoluted ways to Integrate.

      Two of their examples, GIMP and Inkscape, are image and vector editors respectively. They also need additional permissions to work, since making them use portals for all host system file access is technically complicated. Audacity and VLC face similar barriers, but all these applications should eventually be able to use portals instead of direct home or host filesystem access without losing functionality.

      Why? Is there a reason why these applications can’t contain all their resources within the Flatpak, and then only reach out to the filesystem to playback/edit user files?

      Technically speaking, applications are always sandboxed, as the Flatpak developers have stated. Allowing access to the host file system does not give the application full reign over your system.

      But as can be seen in the .bashrc example, it’s trivial to just place something in the filesystem which does have full reign over the user’s files (and the whole system, as soon as the user uses the fake sudo shim implanted into the bashrc).

      Fortunately, this problem has been solved in recent updates. If this problem persisted, I would have criticized it too:

      That screenshot is pretty much what leads to “dialog box fatigue”. Since anything non-trivial will throw up a big warning box that says “this application can escape the sandbox”, at some point users will learn to ignore it. This is not a proper solution.

      A valid point. Since the Flatpak developers were fully aware of this problem, they came up with an acceptable and easy solution: flatpak-external-data-checker (f-e-d-c). f-e-d-c is a tool that automatically checks for external sources, such as dependencies and binaries.

      This requires manual effort from the Flatpak package developers to actually accept the pull request, make sure that the application still works as expected, and then publish a new version on the Flatpak store, after which the users will upgrade to the newest version, eventually. And this will have to happen separately for every app that uses the dependency. If OpenSSL is vulnerable to Heartbleed 2.0 tomorrow, then every Flatpak that depends on OpenSSL (which, I’d say, is >90%) will have to separately bump their dependencies, and publish new versions. Even if the pull request is automated, the act of testing the new version isn’t.

      A lot of flatkill.org’s statements are made to incite fear in the Linux community. […] but basing your arguments on an anonymous post that claims to have “criticized” Flatpak, but provided no statistics or evidence that vulnerabilities have been exploited inside a Flatpak package is not a reliable source of information.

      You can replace “flatkill.org” with this post’s URL and replace Flatpak with X11, and it would still be valid, because the author did the same just a few paragraphs ago.

      1. 5

        This requires manual effort from the Flatpak package developers to actually accept the pull request, make sure that the application still works as expected, and then publish a new version on the Flatpak store, after which the users will upgrade to the newest version, eventually. And this will have to happen separately for every app that uses the dependency. If OpenSSL is vulnerable to Heartbleed 2.0 tomorrow, then every Flatpak that depends on OpenSSL (which, I’d say, is >90%) will have to separately bump their dependencies, and publish new versions. Even if the pull request is automated, the act of testing the new version isn’t.

        Unfortunately, I don’t really think you can get around this. If you are committed to ensuring your software keeps working, every library update must be tested. Of course, traditional package-management systems let maintainers update dependencies for all dependent packages at once.

        1. 4

          I think that you’re right. This is precisely why I advocate Nix as a middle ground; it allows for the behavior of updating a single package and all of its dependencies in a single atomic transaction, without requiring each package to vendor its own entire dependency tree. This can be augmented with tools like nix-bundle to produce Flatpak-style application bundles, while also being available for lightweight local installation and usage.

        2. 3

          Why? Is there a reason why these applications can’t contain all their resources within the Flatpak, and then only reach out to the filesystem to playback/edit user files?

          And user files are going to be scattered all over the filesystem, so you can’t just a priori say “you can only open files in this directory and you can only save files in this directory” unless you want a miserable user experience.

          It looks like the FileChooser portal is a way around this, where the infrastructure itself opens up a filechooser dialog and then does some magic behind the scenes, so you can only read/write files that the user explicitly selects. But integrating that is going to be nontrivial.