4 ms·

The downside, and I view it as a fairly big downside, is that security updates are complicated. When there's a problem in libjpeg or zlib, you can get 99% of t

The downside, and I view it as a fairly big downside, is that security updates are complicated. When there's a problem in libjpeg or zlib, you can get 99% of the affected programs by updating the shared lib and restarting the affected applications. What's more, determining if you are affected is much easier. Compare that to trying to figure out which of your statically compiled applications happen to include the affected version of the library. As with so many choices we need to make in software development, it doesn't distill down to one way simply being better. It's a trade off, and in this case it's not just for disk space, but also for maintainability and easily discovering how exposed you are with respect to security.

GordonS 8y ago
I was going to say much the same thing - static and dynamic linking both have their pros and cons, you can't really say one is categorically better than the other.
- zzzcpan 8y ago
  Dynamic linking doesn't have much pros beyond saving some disk space and some insignificant amount of build time.
  - GordonS 8y ago
    I agree those are small things these days, but IMO the biggest pro is security related - it makes it easier to update libraries when security issues arise. For example, if a new issue is found in OpenSSL, you can update the OS's shared library, but for statically linked apps you're dependant on vendors rebuilding and publishing those apps to link to the new version.
- twblalock 8y ago
  Two solutions may each have pros and cons, but that does not mean that one of the solutions is not better overall.
zzzcpan 8y ago
This is a package management problem, linking has nothing to do with it. Security updates, just like library updates, could simply trigger recreation and rebuild of affected packages. Of course if certain package managers still do this kind of thing manually, it's on them. People shouldn't be manually bumping versions in package sources.
- kbenson 8y ago
  That's only a solution for people using package managers, and people using package managers for everything. People manually build stuff. People also manually install binaries than have their own dependencies (even installed wireshark for Windows? I know for a long time, libpcap was installed separately as a sub-process during install). For example, probably 99% of the people that build their own toolchain for development and pushing to production. People also install separate package management systems (brew, cygwin) that might not have their update mechanisms automatically run, or are infrequently run. This is a compilation and deployment strategy downside. You can mitigate (but not eliminate) this downside through a strong package management system that tracks all this (BTW, is there a package management system in current use that tracks statically compiled dependencies?), but only if users and administrators adhere to strict practices.
  - zzzcpan 8y ago
    If you don't track updates in an automatic way, you are not going to even know whether you need to update something. So there is no point to talk about security updates without implying some reliance on a package management system. There are plenty of package management systems in current use where linking is an ideological or historical choice and has no relevance to security updates.
    - kbenson 8y ago
      > If you don't track updates in an automatic way, you are not going to even know whether you need to update something. With dynamic linking, you may get updates for programs that need them without knowing that it was needed. If you manually build Nginx with shared libraries, and later on some fix for PCRE comes down the line and you update libpcre, your Nginx install takes advantage of that the next time it restarts. This happens whether you manually updated PCRE or a package management system does it for you. This happens for things like Chrome and Firefox too, even though they ship with quite a bit statically compiled. There are still portions they expect the system to provide (if you've even tried to get chrome working on an older system, this becomes obvious). This is an advantage, it exists, and people make use of it all the time. You can try to argue down it's relevance, but without successfully doing so first, I think saying it's pointless is getting ahead of yourself. > There are plenty of package management systems in current use where linking is an ideological or historical choice and has no relevance to security updates. At the very least it would have relevance in that they would need to accurately track package dependencies and would not have the additional benefit of the package failing to install if they got it wrong. I've had plenty of times in the past where package management systems haven't even gotten that right, where everything installs but there's errors about missing libraries because of the way things are loaded on demand for some systems. There are benefits to not relying on some automated or manual tracking of this, where instead if you get it wrong it doesn't work. The fact that it requires a package management to mitigate this problem is itself a downside. To be clear, my argument is there are both upsides and downsides to dynamic linking, and that it's not purely all negative. By arguing against that you're positioning yourself as stating that it's not a trade off, so it's all bad (or all good, but that doesn't seem to be your point). Is that really the position you intend to stand on? It seems rather absolutist.
AnIdiotOnTheNet 8y ago
I agree it's a tradeoff, and if the system is designed competently it'll use a mix of the two, with the base system providing common shared libraries for system interfaces, crypto, networking, widgets, sound, etc. and guaranteeing that they won't break compatibility over a long time frame (unless there's a flaw so huge it warrants it). Then application developers are free to rely on these base components and static link their other dependencies.
twblalock 8y ago
You can patch all of your programs at once when a vulnerability is discovered, and that is nice. However, the vulnerability may have become widespread in the first place because it was distributed in a shared library that everyone had to use. This is a double-edged sword that makes vulnerabilities just as easy to distribute as patches.

GordonS 8y ago

I was going to say much the same thing - static and dynamic linking both have their pros and cons, you can't really say one is categorically better than the other.

zzzcpan 8y ago
Dynamic linking doesn't have much pros beyond saving some disk space and some insignificant amount of build time.
- GordonS 8y ago
  I agree those are small things these days, but IMO the biggest pro is security related - it makes it easier to update libraries when security issues arise. For example, if a new issue is found in OpenSSL, you can update the OS's shared library, but for statically linked apps you're dependant on vendors rebuilding and publishing those apps to link to the new version.
twblalock 8y ago
Two solutions may each have pros and cons, but that does not mean that one of the solutions is not better overall.

zzzcpan 8y ago

This is a package management problem, linking has nothing to do with it. Security updates, just like library updates, could simply trigger recreation and rebuild of affected packages. Of course if certain package managers still do this kind of thing manually, it's on them. People shouldn't be manually bumping versions in package sources.

kbenson 8y ago
That's only a solution for people using package managers, and people using package managers for everything. People manually build stuff. People also manually install binaries than have their own dependencies (even installed wireshark for Windows? I know for a long time, libpcap was installed separately as a sub-process during install). For example, probably 99% of the people that build their own toolchain for development and pushing to production. People also install separate package management systems (brew, cygwin) that might not have their update mechanisms automatically run, or are infrequently run. This is a compilation and deployment strategy downside. You can mitigate (but not eliminate) this downside through a strong package management system that tracks all this (BTW, is there a package management system in current use that tracks statically compiled dependencies?), but only if users and administrators adhere to strict practices.
- zzzcpan 8y ago
  If you don't track updates in an automatic way, you are not going to even know whether you need to update something. So there is no point to talk about security updates without implying some reliance on a package management system. There are plenty of package management systems in current use where linking is an ideological or historical choice and has no relevance to security updates.
  - kbenson 8y ago
    > If you don't track updates in an automatic way, you are not going to even know whether you need to update something. With dynamic linking, you may get updates for programs that need them without knowing that it was needed. If you manually build Nginx with shared libraries, and later on some fix for PCRE comes down the line and you update libpcre, your Nginx install takes advantage of that the next time it restarts. This happens whether you manually updated PCRE or a package management system does it for you. This happens for things like Chrome and Firefox too, even though they ship with quite a bit statically compiled. There are still portions they expect the system to provide (if you've even tried to get chrome working on an older system, this becomes obvious). This is an advantage, it exists, and people make use of it all the time. You can try to argue down it's relevance, but without successfully doing so first, I think saying it's pointless is getting ahead of yourself. > There are plenty of package management systems in current use where linking is an ideological or historical choice and has no relevance to security updates. At the very least it would have relevance in that they would need to accurately track package dependencies and would not have the additional benefit of the package failing to install if they got it wrong. I've had plenty of times in the past where package management systems haven't even gotten that right, where everything installs but there's errors about missing libraries because of the way things are loaded on demand for some systems. There are benefits to not relying on some automated or manual tracking of this, where instead if you get it wrong it doesn't work. The fact that it requires a package management to mitigate this problem is itself a downside. To be clear, my argument is there are both upsides and downsides to dynamic linking, and that it's not purely all negative. By arguing against that you're positioning yourself as stating that it's not a trade off, so it's all bad (or all good, but that doesn't seem to be your point). Is that really the position you intend to stand on? It seems rather absolutist.

AnIdiotOnTheNet 8y ago

I agree it's a tradeoff, and if the system is designed competently it'll use a mix of the two, with the base system providing common shared libraries for system interfaces, crypto, networking, widgets, sound, etc. and guaranteeing that they won't break compatibility over a long time frame (unless there's a flaw so huge it warrants it). Then application developers are free to rely on these base components and static link their other dependencies.

twblalock 8y ago

You can patch all of your programs at once when a vulnerability is discovered, and that is nice. However, the vulnerability may have become widespread in the first place because it was distributed in a shared library that everyone had to use. This is a double-edged sword that makes vulnerabilities just as easy to distribute as patches.