16
Appimages, snaps and flatpaks (lemmy.world)
submitted 3 years ago by to c/linux@lemmy.ml
63 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 3 years ago (1 child)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •