9 ms·

So next time a library such as OpenSSL has a critical security vulnerability that needs to be patched, you'd rather every single binary that has it statically l

• rattlesnakedave 4y ago
  Google “OpenSSL dependency conflict” and view the results. There is significantly more work going on when OpenSSL releases and update than “just update the single shared library file.” Applications often need to be updated as well, so you may as well just statically link the new binary.
  • nicce 4y ago
    It really depends on whether the bug is in API or not. If it is not, it is likely that upgrading only the shared library is enough.
    • convolvatron 4y ago
      How lovely to live in a world where api contracts are absolute and complicated internal behaviors never conflict in unforeseen ways. We’ve really gotten on top of the software complexity problem
      • hedora 4y ago
        That's exactly the problem deb files and apt solve (via integration testing and documenting antidependences.)
      • arinlen 4y ago
        > How lovely to live in a world where api contracts are absolute and complicated internal behaviors never conflict in unforeseen ways. Some libraries managed to preserve API contracts throughout the years just fine. Even in C++, a language which does not establish a standard ABI, has frameworks which have not been breaking the ABI throughout multiple releases, such as Qt.
  • itvision 4y ago
    Haven't seen a single OpenSSL issue over the past 25 years of using Linux. libstdc++ errors? Seen them.
    • pfarrell 4y ago
      Libstdc++ errors notwithstanding, what about heartbleed? https://en.m.wikipedia.org/wiki/Heartbleed https://en.m.wikipedia.org/wiki/Heartbleed
      • RealStickman_ 4y ago
        I think the parent was talking about dependency conflicts, not issues in OpenSSL.
• Ericson2314 4y ago
  If you keep around the .o / .a files this isn't so bad.
• ori_b 4y ago
  Sure. Networks are fast enough.
  • hlsnqp 4y ago
    What about closed-source binaries where a patched binary can't be obtained from the vendor?
    • eru 4y ago
      You could link locally, or you could opt not to use them. Or you could restrict dynamic linking to these special cases.
    • ori_b 4y ago
      The same thing I do if the vulnerability is in the binary itself, and not in a library. Surely, if you care, you have a mitigation plan for this?
    • vbezhenar 4y ago
      Binary patch it.
    • Beltalowda 4y ago
      With closed-source binaries the argument for static linking is the strongest, IMHO, or at least shipping all the required shared libraries and LD_LIBRARY_PATH that in. The amount of times I've had to muck about to make a five-year old game work on a current system is somewhat bonkers, and I would never expect someone unfamiliar with shared library details (i.e. a normal non-tech person, or even a tech person not familiar with C/Linux) to figure all of that out.
    • IshKebab 4y ago
      Closed source programs almost universally bundle all dependencies (except system ones) irrespective of whether they are using static or dynamic linking. They have to to ensure that they actually run reliably.
  • eru 4y ago
• alkonaut 4y ago
  This argument comes up every time this discussion comes up (on flatpaks etc). And for almost all systems I’d say “yes, absolutely”. One headache over another. What’s to guarantee applications haven’t statically linked a library (in whatever version) rather than linked a “system” version of a library? With the dynamic one you have both problems…
  • LtWorf 4y ago
    Flatpaks won't be automatically recompiled though. It might take years before they bump whatever vulnerable thing they are using. > What’s to guarantee applications haven’t statically linked a library (in whatever version) rather than linked a “system” version of a library? It's easy to see which commands are given to the compiler and if there is a copied library if you have sources.
    • gravypod 4y ago
      > Flatpaks won't be automatically recompiled though. It might take years before they bump whatever vulnerable thing they are using. If we made all builds reproducible (like oasis) we could setup an automated trusted system that does builds verifiably automatically (like what Nix has).
      • goodpoint 4y ago
        There are already trusted sources of software packages that provide security updates: traditional Linux distributions. Doing automated, local patching and rebuilding is far from enough. You need experts to correctly backport patches and test them thoroughly.
        • bayindirh 4y ago
          No, no… We need to move very fast, and break all the things. Tradition and conservatism is not the way. We need to compile everything and anything. Change the paradigm, break the status quo! Oh, just like Gentoo, Slackware and LFS. ;) Seriously, maybe we shouldn’t ignore history and learn why things are like this today.
• waynecochran 4y ago
  Yes. I can think of worse problems w shared libs. Should we start a list?
• kortex 4y ago
  In the majority of cases: Absolutely. That is basically the direction things have gone with "just docker build the image and redeploy". The amount of frustration dynamic linking causes is just not worth it in today's day. I think that calculus looks very different 20, 10, maybe even 5 years ago, when getting packages rebuilt and distributed from a zillion different vendors was much harder.
  • Wowfunhappy 4y ago
    This. If we'd just statically link executables, we wouldn't need Docker. Docker is a solution for a problem that only exists because of dynamic linking, and the tool's popularity should be a wakeup call.
    • maccard 4y ago
      That's not true. Docker/containers do far more than just bundle shared libraries. We use a container for almost all of our CI builds. Our agents are container images with the toolchains, etc installed. It also means it's trivially easy to reproduce the build environment for those occasional wtf moments where someone has an old version of <insert tool here>.
      • Wowfunhappy 4y ago
        But if the tools were all statically linked, couldn't you ship a zip with the binaries needed for building?
        • benreesman 4y ago
          Indeed, you could. Linus takes backward compatibility more than a little seriously.
        • maccard 4y ago
          How do you update those tools and make sure you've deleted all the old versions? What do you do to avoid the problem of a developer SSH'ing and apt-get installing a build dependency? Tools aren't the only part of the environment though. Setting the JAVA_HOME environment variable for a build can dramatically change the output, for example. Path ordering might affect what version of a tool is launched. They also mean that our developers don't need to run centos 7, they can develop on windows or Linux, and test on the target platform locally from their own machine.
• flohofwoe 4y ago
  Considering the complexity that shared libraries add over static linking: yes absolutely.
  • palata 4y ago
    Is that only that good libraries should correctly use semver (i.e. be backward-compatible unless they change the major version), or is there complexity somewhere else? My feeling is that dynamic linking is a pain because sometimes one needs, say, 1.2.5 for some part of the code and 1.3.1 for another part, and they are not compatible. Which hints towards the library author having messed up something, right?
• glowingly 4y ago
  We just didn't update Log4j since it broke a critical, old, closed source offline program. Vendor has long dropped support for this old program. Cue that up to the usual executive missteps that we get from up high. Yay, we get to keep on using old Log4j now because one program holds it back.
  • cesarb 4y ago
    If the "old log4j" is 1.2.x, you can update to reload4j (https://reload4j.qos.ch/ https://reload4j.qos.ch/), which is a fork of the latest log4j 1.2.x by its initial author; you don't have to update to log4j 2.x (which changed the API). And you might not even need to update, since "old log4j" (1.2.x) wasn't affected by that vulnerability in the first place (it has its own old vulnerabilities, but they're all in code which is usually not used by real world deployments).
• indy 4y ago
  Yes
• enriquto 4y ago
  > you'd rather every single binary that has it statically linked is updated, rather than a single shared library file? Yes! A thousand times yes. I'd rather reinstall every single compromised program than deal with the ridiculous complexity of dynamic linking.
  • e40 4y ago
    In some cases it’s impossible to build older software, or very difficult.
• worldshit 4y ago
  you only need to relink, not recompile. i think oasis caches artifacts so there's no overhead.
• marssaxman 4y ago
  Oh, yes, I certainly would. Shared libraries are an expensive, trouble-prone solution for that relatively uncommon problem. Anyway that's not why we have shared libraries. They were invented so that memory managers could load the same library once, then map it into the address space for every process which used it. This kind of savings mattered back when RAM was expensive and executable code represented a meaningful share of the total memory a program might use. Of course that was a very long time ago now.
  • benreesman 4y ago
    Also: text pages are shared in the typical case. It was largely a spurious argument to begin with. If it didn't fuck over `musl` et. al. and `libstdc++` it would have been relegated to corner cases years ago.
    • comex 4y ago
      Is your first sentence missing a negation, or can you elaborate?
      • benreesman 4y ago
        I should have been more precise, but that can become a treatise by HN comment standards easily so consider there to be an asterisk next to all of this for myriad platform/toolchain corner cases. To the extent that shared libraries economize on memory, or are claimed to, it's when a lot of different processes link the same version of the same library, e.g. your `libc` (or the original motivating example of X). The tradeoff here is that the kernel has an atomic unit of bringing data into RAM (AKA "core" for the old-timers), which is usually a 4kb page, and shared libraries are indivisible: you use `memcpy` and you get it and whatever else is in the 4kb chunk somebody else's linker put it in. Not a bad deal for `memcpy` because it's in everything, but a very bad deal for most of the symbols in e.g. `glibc`. The counter-point is that with static linking, the linker brings in only the symbols you use. You do repeat those symbols for each `ELF`, but not for each process. This is often (usually?) a better deal. A little poking around on my system to kind of illustrate this a bit more viscerally: https://pastebin.com/0zpVqA0r https://pastebin.com/0zpVqA0r (apologies for the clumsy editing, it would be too long if I left in every symbol from e.g. `glibc`). Admittedly, that's a headless machine, and some big clunky Gnome/Xorg thing might tell a different story, but it would have to be 100-1000x worse to be relevant in 2022, and almost certainly wouldn't offset the (heinous) costs. And while this is speculation, I think it would be negative worse, because there just aren't that many distinct `ELF`'s loaded on any typical system even with a desktop environment. Chromium or whatever is going to be like, all your RAM even on KDE. There are couple of great CppCon talks that really go deep here (including one by Matt Godbolt!): https://www.youtube.com/watch?v=dOfucXtyEsU https://www.youtube.com/watch?v=dOfucXtyEsU, https://www.youtube.com/watch?v=xVT1y0xWgww https://www.youtube.com/watch?v=xVT1y0xWgww. Don't be put off by the fact it's CppCon, all your GNU stuff is the same story.