4 ms·

And AppImage distribution has the same fundamental security problem as static binaries, making it difficult or impossible to replace downstream dependencies. W

And AppImage distribution has the same fundamental security problem as static binaries, making it difficult or impossible to replace downstream dependencies. When a dynamic library needs a security update (e.g. heartbleed in libssl), the shared library can be replaced system-wide. When a static executable or AppImage needs a newer version of a library, you need to update the program entirely, and there is no way to do so across all programs system-wide.

torstenvl 3y ago
And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. But on a system where everything is updated at the same time through a package manager, I don't see that there's a material difference, unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.
- kpw94 3y ago
  > And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected What's more common in practice ? Widely used libraries introducing critical vulnerabilities in 2023. Or old vulnerabilities being discovered/exploited, and patched? > unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage. That's precisely the problem isn't it? What if "You the upstream app developer" is on a long vacation, or abandoned the project? Multiply this by N where N is the number of different app developers. Compare with "you as the OS admin". If you're using your system, you update that vulnerable dynamic library, and you're done. If users of other machines are on vacation or abandoned their machine, that's not your problem. Your system is secure. So I feel parent's point had everything to do with dynamic vs. static linkage.
- ilyt 3y ago
  > And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. Bugs discovered in older version of libraries are far more common than newly introduced ones. Also, distros usually keep to whatever release line is deemed "stable" vs "whatever appimage author decide to put there"
- ZiiS 3y ago
  You only need one hole. A newly introduced vulnerability compromises the system as soon as one package updates. A fixed dependency only works when every single program is updated.
- MereInterest 3y ago
  If a new version of a dependency introduces a vulnerability, then dynamic libraries allow you as the sysadmin to stick with the secure version. For package managers, difference is how often the decision to update a library must be made. Dynamic libraries mean that the package maintainer of libFOO must be aware of security issues in libFOO, and update accordingly. Static libraries or AppImages mean that the package maintainer of every user of liBFOO must be aware of security updates in libFOO, which is a much higher burden.

torstenvl 3y ago

And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. But on a system where everything is updated at the same time through a package manager, I don't see that there's a material difference, unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.

kpw94 3y ago
> And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected What's more common in practice ? Widely used libraries introducing critical vulnerabilities in 2023. Or old vulnerabilities being discovered/exploited, and patched? > unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage. That's precisely the problem isn't it? What if "You the upstream app developer" is on a long vacation, or abandoned the project? Multiply this by N where N is the number of different app developers. Compare with "you as the OS admin". If you're using your system, you update that vulnerable dynamic library, and you're done. If users of other machines are on vacation or abandoned their machine, that's not your problem. Your system is secure. So I feel parent's point had everything to do with dynamic vs. static linkage.
ilyt 3y ago
> And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. Bugs discovered in older version of libraries are far more common than newly introduced ones. Also, distros usually keep to whatever release line is deemed "stable" vs "whatever appimage author decide to put there"
ZiiS 3y ago
You only need one hole. A newly introduced vulnerability compromises the system as soon as one package updates. A fixed dependency only works when every single program is updated.
MereInterest 3y ago
If a new version of a dependency introduces a vulnerability, then dynamic libraries allow you as the sysadmin to stick with the secure version. For package managers, difference is how often the decision to update a library must be made. Dynamic libraries mean that the package maintainer of libFOO must be aware of security issues in libFOO, and update accordingly. Static libraries or AppImages mean that the package maintainer of every user of liBFOO must be aware of security updates in libFOO, which is a much higher burden.