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

  • 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
      arrow-down
      1
      ·
      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.