Appimages, snaps and flatpaks, which one do you prefer and why?

  • vrighter@discuss.tchncs.de
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago

    none of them. I don’t like the idea of putting security updates in the hands of the developers of each individual application I use.

    Oh your app only works with an old broken insecure version of the library? Fuck you then, you can’t just decide to install and use the insecure version.

    • dino@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      Interesting idea, didn’t think about this before. Still you could argue because of the sandboxed nature, those outdated libraries should’nt be much of a problem?

      • vrighter@discuss.tchncs.de
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        example, suppose there was a bug in openssl’s prime number generation code. It will generate insecure keys.

        No amount of sandboxing can help with that. The bug is discovered and the next day I run ‘pacman -Syu’ (I use arch, btw) and the problem is gone systemwide, except for any flatpaks or appimages etc. Those will only get updates (and stop leaking my data) if and only if its maintainer actually gives a fuck, is still alive and active. If not, you’re sol

        • dino@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          I am very certain the most appropriate person to update the software would be the developer itself. So when suddenly for flatpaks & co the responsibility of updating libraries is put on the flatpak package maintainer for ANYTHING used in that container… it doesn’t sound optimal.

          Still your example is a very edge-case scenario, because it would create a static vulnerability.

          • vrighter@discuss.tchncs.de
            link
            fedilink
            arrow-up
            2
            ·
            1 year ago

            Containers are a form of static linking. just because they are different files inside the image, doesn’t mean they’re not effectively statically linked, if they can only be upgraded together

            If I update my shared libraries, that application uses its own ‘statically linked’ libraries and doesn’t pick up the changes. Exactly like what happens with a normal statically linked binary.

            I avoid static linking like the plague.

      • vrighter@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        sandboxing protects apps from each other. If there’s a bug in some library that somehow leaks some security keys or something, sandboxing doesn’t help.

        • dino@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          “leaks security keys of the app itself”, it can’t leak anything outside of the container?