5 ms·

And right about here is where the claims that dynamic linking is better for everyone's security update schedule just falls apart, for this reader. Dynamic link

And right about here is where the claims that dynamic linking is better for everyone's security update schedule just falls apart, for this reader. Dynamic linking does not make it easier to update things. There, I said it. Updating things confidently and safely requires -- as the article wisely references -- testing those things, and the entire matrix of other things they interact with. Static vs dynamic linking simply doesn't register. In either case, the newer versions need to be built, and then tested together. The only thing dynamic linking does is make it possible for distros to hamstring themselves[^] by tossing everything into one big cauldron, so nothing can be upgraded because it requires testing too much at once. And here's the endgame. "Is OpenSSL getting updated on $distro?" "Nope." Sigh. --- [^] And this is a red herring, in turn: dynamic linking isn't the real enemy either; it's the global sloppile approach to sharing dynamic linked libraries that really causes the mess. NixOS and others like that still use dynlinking, and yet have successfully immunized themselves from these problems by using content-addressable library versioning. So let's stop with the "dynlinking is better for security updates" claims. It's not. It's either unrelated at best, or actively a ball-and-chain making things harder and slower, and I submit as evidence OpenSSL versions across these distros.

hvs 10y ago
I agree. Anyone who thinks that dynamic linking makes things easier to update never lived through the DLL-hell of Windows where installing one new product would break a completely unrelated one because it "upgraded" a library.
- pjmlp 10y ago
  True, specially when dealing with classical COM. However for plugins when performance is critical, is a good use case. For anything else, as the last decade as shown us, it is probably better to use OS IPC instead of exposing the application internals to third parties.
stingraycharles 10y ago
I would be the first to agree that dynamic linking is evil, but how is this related with the issue at hand, which is client-to-server communication? No amount of static linking of Chrome would magically upgrade the SSL version being used to package Debian, for example. What am I missing here?
- heavenlyhash 10y ago
  Chrome did not previously rely on a dynlinked system library for the negotiation feature. Now, evidently, it does. In making this transition, Chrome experienced a massive practical regression for many users, precisely because the dynlinked library is not sufficiently up to date for many people. I'd say dynamic linking is related to the issue at hand, yeah.
  - slrz 10y ago
    No, it's not. The article is about missing support on the server side, not in Chrome.
    - deleted 10y ago
      [deleted]
- coldtea 10y ago
  >No amount of static linking of Chrome would magically upgrade the SSL version being used to package Debian, for example. No, but if Debian packages had statically compiled OpenSSL you could just update say Nginx and get it working with the new protocol Chrome requires, while 100+ packages could still be left as is and use their own, older, version of the lib.
atesti 10y ago
What happens if a program is statically linked to OpenSSL 1.0.2, but dynamically linked to a library like libpq (Postgres client) and this is linked to an older OpenSSL version?
- oliwarner 10y ago
  The respective codebases ("a program", libpq) would use their own linked versions to execute their code. So yes, two different versions but is that automatically bad? It could be, but remember that exploits, even serious ones, are usually on very discrete vectors. It can be hard to exploit something abstracted away through two application layers.
kelnos 10y ago
There is absolutely nothing stopping someone from packaging OpenSSL 1.0.2 for the distros that don't have it included by default. It's trivial to parallel-install different OpenSSL versions, though admittedly with most distros it requires some special attention at build time to build things (such as nginx) against the newer version. You hint at this is in your postscript but don't do it the attention it deserves. Google could even take this on and put up apt/yum repos supporting various versions of various distros; with their resources and infrastructure it wouldn't even be that much work. Also your argument has nothing to do with security updates, and I'd maintain that dynamic linking does indeed make security updates easier, since you still only have one package to update rather than some potentially large N.[0] Yes, there is still the burden of testing dependent packages, but at least they don't need to be rebuilt. I would argue it's safer from a security perspective, as it's always possible to forget that a particular statically-linked package needs to be rebuilt. At my org we used to have a few special-flower services that needed a newer version of OpenSSL and were statically linked. This just meant more work after every security disclosure. (Arguably we "did it wrong": instead of static linking, we should have just built and installed the shared lib and linked to it, making it easier to identify and track what needed to be updated.) [0] At least for the case where a patched update can be released, one that doesn't have ABI changes. If you're running a distro that is using an EOLed version of a library, I'm sympathetic, but ultimately that is a problem larger than the one at hand that you need to solve.

hvs 10y ago

I agree. Anyone who thinks that dynamic linking makes things easier to update never lived through the DLL-hell of Windows where installing one new product would break a completely unrelated one because it "upgraded" a library.

pjmlp 10y ago
True, specially when dealing with classical COM. However for plugins when performance is critical, is a good use case. For anything else, as the last decade as shown us, it is probably better to use OS IPC instead of exposing the application internals to third parties.

stingraycharles 10y ago

I would be the first to agree that dynamic linking is evil, but how is this related with the issue at hand, which is client-to-server communication? No amount of static linking of Chrome would magically upgrade the SSL version being used to package Debian, for example. What am I missing here?

heavenlyhash 10y ago
Chrome did not previously rely on a dynlinked system library for the negotiation feature. Now, evidently, it does. In making this transition, Chrome experienced a massive practical regression for many users, precisely because the dynlinked library is not sufficiently up to date for many people. I'd say dynamic linking is related to the issue at hand, yeah.
- slrz 10y ago
  No, it's not. The article is about missing support on the server side, not in Chrome.
  - deleted 10y ago
    [deleted]
coldtea 10y ago
>No amount of static linking of Chrome would magically upgrade the SSL version being used to package Debian, for example. No, but if Debian packages had statically compiled OpenSSL you could just update say Nginx and get it working with the new protocol Chrome requires, while 100+ packages could still be left as is and use their own, older, version of the lib.

atesti 10y ago

What happens if a program is statically linked to OpenSSL 1.0.2, but dynamically linked to a library like libpq (Postgres client) and this is linked to an older OpenSSL version?

oliwarner 10y ago
The respective codebases ("a program", libpq) would use their own linked versions to execute their code. So yes, two different versions but is that automatically bad? It could be, but remember that exploits, even serious ones, are usually on very discrete vectors. It can be hard to exploit something abstracted away through two application layers.

kelnos 10y ago

There is absolutely nothing stopping someone from packaging OpenSSL 1.0.2 for the distros that don't have it included by default. It's trivial to parallel-install different OpenSSL versions, though admittedly with most distros it requires some special attention at build time to build things (such as nginx) against the newer version. You hint at this is in your postscript but don't do it the attention it deserves. Google could even take this on and put up apt/yum repos supporting various versions of various distros; with their resources and infrastructure it wouldn't even be that much work. Also your argument has nothing to do with security updates, and I'd maintain that dynamic linking does indeed make security updates easier, since you still only have one package to update rather than some potentially large N.[0] Yes, there is still the burden of testing dependent packages, but at least they don't need to be rebuilt. I would argue it's safer from a security perspective, as it's always possible to forget that a particular statically-linked package needs to be rebuilt. At my org we used to have a few special-flower services that needed a newer version of OpenSSL and were statically linked. This just meant more work after every security disclosure. (Arguably we "did it wrong": instead of static linking, we should have just built and installed the shared lib and linked to it, making it easier to identify and track what needed to be updated.) [0] At least for the case where a patched update can be released, one that doesn't have ABI changes. If you're running a distro that is using an EOLed version of a library, I'm sympathetic, but ultimately that is a problem larger than the one at hand that you need to solve.