4 ms·

Somebody tell me again about the supposed benefits of dynamic linking, if we have to recompile and redistribute all the dependent packages for every OpenSSL upg

Somebody tell me again about the supposed benefits of dynamic linking, if we have to recompile and redistribute all the dependent packages for every OpenSSL upgrade anyway?

reidrac 10y ago
I think it is because OpenSSL changes the API frequently and it'll break things in subtle ways. I may be wrong, but this is not a problem with dynamic linking but with OpenSSL as a project.
mcguire 10y ago
1.0.1 -> 1.0.2 would be invisible to API users, in a slightly better world, anyway.
acdha 10y ago
> if we have to recompile and redistribute all the dependent packages for every OpenSSL upgrade anyway? Because we don't – look at how many updates Debian, Red Hat, etc. have shipped for OpenSSL vs. the number of times you've had to recompile dependent packages. OpenSSL is also something an outlier because it's both critically exposed for security and has a somewhat unusual development model, so it's also important to remember that even if it _was_ true that we have to rebuild OpenSSL callers regularly, that's manifestly not true of the hundreds of other libraries where dynamic linking saves time and memory.
- fixermark 10y ago
  It's honestly so mission-critical to interactions on the internet---and computers are so increasingly assumed to be on the internet---it's a bit of a wonder that no-one to my knowledge has tried to roll it into the kernel as a core and necessary function yet.
  - predakanga 10y ago
    It's definitely been discussed[1]. I last read about it when investigating the use of splice(2) in nginx; seems there are a few use-cases, but nothing really compelling. [1]: https://lwn.net/Articles/666509/ https://lwn.net/Articles/666509/
0x0 10y ago
1.0.1->1.0.2 is major upgrade (it's more like an "openssl 2.x to 3.x" type update). Static linking wouldn't help you because when you go to recompile you'll most likely discover compilation fails because the API changed. For 1.0.1x->1.0.1y upgrades, dynamic linking means you just update the lib and restart running services, no recompilation needed. No random little-used binary hanging around with an old embedded static openssl, hopefully, as they will all pick up the patches as long as they dynamically link to the updated .so
- wmf 10y ago
  If it's a major upgrade then distros should make 1.0.1 and 1.0.2 parallel installable [1] so that apps can opt in to updating. [1] just kidding; I know distros don't have nearly enough resources to accomplish this
  - 0x0 10y ago
    It would be technically possible but then they would end up having to maintain and offer two sets of every dependency, i.e. apache-ssl101 and apache-ssl102. Also, distros usually freeze what they have, so this would only be of interest for backports or perhaps if there was a need to supply old openssl versions even if a newer one is available before the freeze. The "solution" here is just to wait it out for new major releases of the various distros, and not expect everyone to change core libraries every six months :)
    - wmf 10y ago
      For example, Debian Jessie shipped with 1.0.1 even though 1.0.2 was already out, probably because not every app had been ported to 1.0.2 yet. But their "megafreeze" development model amplifies a 6-month scale problem into a many-year problem. If they had shipped both 1.0.1 and 1.0.2 then apps could have incrementally switched over at their own pace. Naturally, each app would only link against one version of OpenSSL so there'd be no need for apache-ssl101 and apache-ssl102.
      - 10y ago

Somebody tell me again about the supposed benefits of dynamic linking, if we have to recompile and redistribute all the dependent packages for every OpenSSL upgrade anyway?

reidrac 10y ago

I think it is because OpenSSL changes the API frequently and it'll break things in subtle ways. I may be wrong, but this is not a problem with dynamic linking but with OpenSSL as a project.

mcguire 10y ago

1.0.1 -> 1.0.2 would be invisible to API users, in a slightly better world, anyway.

acdha 10y ago

> if we have to recompile and redistribute all the dependent packages for every OpenSSL upgrade anyway? Because we don't – look at how many updates Debian, Red Hat, etc. have shipped for OpenSSL vs. the number of times you've had to recompile dependent packages. OpenSSL is also something an outlier because it's both critically exposed for security and has a somewhat unusual development model, so it's also important to remember that even if it _was_ true that we have to rebuild OpenSSL callers regularly, that's manifestly not true of the hundreds of other libraries where dynamic linking saves time and memory.

fixermark 10y ago
It's honestly so mission-critical to interactions on the internet---and computers are so increasingly assumed to be on the internet---it's a bit of a wonder that no-one to my knowledge has tried to roll it into the kernel as a core and necessary function yet.
- predakanga 10y ago
  It's definitely been discussed[1]. I last read about it when investigating the use of splice(2) in nginx; seems there are a few use-cases, but nothing really compelling. [1]: https://lwn.net/Articles/666509/ https://lwn.net/Articles/666509/

0x0 10y ago

1.0.1->1.0.2 is major upgrade (it's more like an "openssl 2.x to 3.x" type update). Static linking wouldn't help you because when you go to recompile you'll most likely discover compilation fails because the API changed. For 1.0.1x->1.0.1y upgrades, dynamic linking means you just update the lib and restart running services, no recompilation needed. No random little-used binary hanging around with an old embedded static openssl, hopefully, as they will all pick up the patches as long as they dynamically link to the updated .so

wmf 10y ago
If it's a major upgrade then distros should make 1.0.1 and 1.0.2 parallel installable [1] so that apps can opt in to updating. [1] just kidding; I know distros don't have nearly enough resources to accomplish this
- 0x0 10y ago
  It would be technically possible but then they would end up having to maintain and offer two sets of every dependency, i.e. apache-ssl101 and apache-ssl102. Also, distros usually freeze what they have, so this would only be of interest for backports or perhaps if there was a need to supply old openssl versions even if a newer one is available before the freeze. The "solution" here is just to wait it out for new major releases of the various distros, and not expect everyone to change core libraries every six months :)
  - wmf 10y ago
    For example, Debian Jessie shipped with 1.0.1 even though 1.0.2 was already out, probably because not every app had been ported to 1.0.2 yet. But their "megafreeze" development model amplifies a 6-month scale problem into a many-year problem. If they had shipped both 1.0.1 and 1.0.2 then apps could have incrementally switched over at their own pace. Naturally, each app would only link against one version of OpenSSL so there'd be no need for apache-ssl101 and apache-ssl102.
    - 10y ago