• @federico3
    link
    -12 years ago

    This is a Flatpak problem. Its design requires the user to either trust the upstream developers to set the sandboxing properly or learn how to do it and spend time configuring each and every application as needed. This is not practical.

    In traditional Linux distributions there is a trusted package mantainer that reviews software and configurations with the user’s needs in mind.

    • @Ferk
      link
      2
      edit-2
      2 years ago

      or learn how to do it and spend time configuring each and every application as needed

      And even if they were to spend the time, afaik there’s simply no right way to configure a flatpak like GIMP so it can edit any file from any arbitrary location they might want without first giving it read/write permissions for every single of those locations and allowing the program to access those whole folder trees at any point in time without the user knowing (making it “unsafe”).

      It shouldn’t have to be this way, there could be a Flatpak API for requesting the user for a file to open with their explicit consent, without requiring constant micro-management of the flatpak settings nor pushing the user to give it free access to entire folders. The issue is that Flatpak tries to be transparent to the app devs so such level of integration is unlikely to happen with its current philosophy.

      • @federico3
        link
        02 years ago

        there could be a Flatpak API for requesting the user for a file to open with their explicit consent

        That would not be Flatkpak then. It would be an OS component, much like Android has a file opener implemented as an independent process IIRC.

        • @Ferk
          link
          0
          edit-2
          2 years ago

          That’s a very loose definition of “OS Component”. At that point you might as well consider the web browser an “OS Component” too, or frameworks like Retroarch, who offer a filesystem API for their libretro cores.

          But even if we accepted that loose definition, so what? even as it is today Flatpak is already an “OS Component” integrated already in many distros (it’s even a freedesktop.org standard), and it already implements a filesystem interface layer for its apps. As I said, I think the real reason they won’t do it is because they keep wanting to be transparent to the app devs (ie. they don’t want them to have to support Flatpak-specific APIs). Which is why I think there needs to be a change of philosophy if they want app containerization to be seamless, safe and generally useful.

          • @federico3
            link
            02 years ago

            You are missing the point. A process-independent file opener that is used by all applications to access files provides user-friendly security. This would be a core component of an OS so the description is correct.

            • @Ferk
              link
              0
              edit-2
              2 years ago

              You are missing the point. A process-independent file opener that is used by all applications to access files provides user-friendly security.

              But that was essentially what I said… I’m the one who proposed something like that 2 comments ago.

              This would be a core component of an OS so the description is correct.

              Again, I disagree that “this would be a core component of an OS”. You did not address any of my points, so I don’t see how it follows that “the description is correct”. The term “core OS component” is subjective to begin with.

              But even if you wanted to label it that way, it wouldn’t make any difference. That’s just a label you are putting on it, it would not make Flatpak any less of an app distribution / management system with focus on cross-distro compatibility and containerization. Flatpak would still be Flatpak. Whether or not you want to consider it a core part of the OS is not important.

              And Flatpak already uses independent processes to manage the whole container & runtime that the app uses for access to the system resources, which already closely matches what you defined as “a core component of an OS”.