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.
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 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.
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.
ELI5?