4 ms·

I've never gotten the hate for static linking, which would avoid issues like this. You'd always have the version of your dependencies that you're expecting. A

I've never gotten the hate for static linking, which would avoid issues like this. You'd always have the version of your dependencies that you're expecting. Also, dynamic linking completely neuters LTO. There's not much point to (theoretically) saving a few megabytes of RAM when you're pulling in twice as much unused code.

pathseeker 8y ago
>I've never gotten the hate for static linking vulnerabilities
- DrScientist 8y ago
  Sure - but most computers are used by people who are the sole user, so local user to user security as a concept isn't useful. Most code isn't part of the remote attack surface. Also there would be no software bugs if bugs only existed in the past... ie bugs come with updates, not just fixed by updates. There are trade offs, and Linux developers decided to make it what was easiest for them and remove the ability for the user to choose. If there wasn't a need for stability and isolation then docker et al wouldn't exist.
- juliangoldsmith 8y ago
  Based on what cesarb said, that's a problem with the build system.
cesarb 8y ago
> I've never gotten the hate for static linking I believe most of the dislike for static linking can be traced to a single incident: a really bad (as in "remote code execution" bad) vulnerability in zlib, CVE-2002-0059. Back then, it was common to statically link to zlib (and zlib is a very popular library, the DEFLATE algorithm it implements being the "standard" compression algorithm), so instead of just replacing a single dynamic library and rebooting, everything had to be audited for the presence of embedded copies of zlib. Quoting from a message from a few years later (http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000055.html http://mail.openjdk.java.net/pipermail/build-dev/2007-May/00...): "[...] Updating the main system zlib package was easy, but finding all the embedded copies was a nightmare. I think we ended up grepping every binary and library in every package for symbols and other bits of code that looked like zlib. All the different versions involved compounded this. And when everything is found and patched and built and tested there's the cost of bandwidth to distribute all the extra stuff. So when people talk of removing static libraries they're talking about real costs -- time and money. After zlib there was a definite feeling of "never again"."
- Hello71 8y ago
  That's not a complaint about static linking though, that's a complaint about library embedding. Lots of Professional Enterprise Software as well as poorly designed games use a buttload of dynamic linking, but a few patches here and there and some API/ABI ignorance later, the libraries are impossible to replace.
- TFortunato 8y ago
  Unfortunately, this is conflating static linking with bad dependency management. ("Just copy it into your own repo", is a different step, that is unnecessary to do the second step, "and link it statically") There is no reason I see why you couldn't just have a build that produces the library .a file for zlib, which can then be pulled in as a dependency of your build / linked in statically. I totally agree, they had a nightmare situation on their hands, but I don't think static linking was solely to blame :-)
  - tedunangst 8y ago
    I have 100s of binaries on my system. Which ones do I need relink?
    - juliangoldsmith 8y ago
      You can write a script to look at package files' makedepends, and rebuild everything that uses the offending library.
tedunangst 8y ago
> There's not much point to (theoretically) saving a few megabytes of RAM when you're pulling in twice as much unused code. But there is. The unused code is still shared.
- juliangoldsmith 8y ago
  That might make a marginal difference if you have large libraries that are used in a large number of applications that run concurrently. Otherwise, the sharing is completely pointless.
- caf 8y ago
  ...and the libraries are typically demand-paged as well, so the truly unused stuff isn't even resident.
  - juliangoldsmith 8y ago
    That would assume that used and unused code aren't mixed within pages.

pathseeker 8y ago

>I've never gotten the hate for static linking vulnerabilities

DrScientist 8y ago
Sure - but most computers are used by people who are the sole user, so local user to user security as a concept isn't useful. Most code isn't part of the remote attack surface. Also there would be no software bugs if bugs only existed in the past... ie bugs come with updates, not just fixed by updates. There are trade offs, and Linux developers decided to make it what was easiest for them and remove the ability for the user to choose. If there wasn't a need for stability and isolation then docker et al wouldn't exist.
juliangoldsmith 8y ago
Based on what cesarb said, that's a problem with the build system.

cesarb 8y ago

> I've never gotten the hate for static linking I believe most of the dislike for static linking can be traced to a single incident: a really bad (as in "remote code execution" bad) vulnerability in zlib, CVE-2002-0059. Back then, it was common to statically link to zlib (and zlib is a very popular library, the DEFLATE algorithm it implements being the "standard" compression algorithm), so instead of just replacing a single dynamic library and rebooting, everything had to be audited for the presence of embedded copies of zlib. Quoting from a message from a few years later (http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000055.html http://mail.openjdk.java.net/pipermail/build-dev/2007-May/00...): "[...] Updating the main system zlib package was easy, but finding all the embedded copies was a nightmare. I think we ended up grepping every binary and library in every package for symbols and other bits of code that looked like zlib. All the different versions involved compounded this. And when everything is found and patched and built and tested there's the cost of bandwidth to distribute all the extra stuff. So when people talk of removing static libraries they're talking about real costs -- time and money. After zlib there was a definite feeling of "never again"."

Hello71 8y ago
That's not a complaint about static linking though, that's a complaint about library embedding. Lots of Professional Enterprise Software as well as poorly designed games use a buttload of dynamic linking, but a few patches here and there and some API/ABI ignorance later, the libraries are impossible to replace.
TFortunato 8y ago
Unfortunately, this is conflating static linking with bad dependency management. ("Just copy it into your own repo", is a different step, that is unnecessary to do the second step, "and link it statically") There is no reason I see why you couldn't just have a build that produces the library .a file for zlib, which can then be pulled in as a dependency of your build / linked in statically. I totally agree, they had a nightmare situation on their hands, but I don't think static linking was solely to blame :-)
- tedunangst 8y ago
  I have 100s of binaries on my system. Which ones do I need relink?
  - juliangoldsmith 8y ago
    You can write a script to look at package files' makedepends, and rebuild everything that uses the offending library.

tedunangst 8y ago

> There's not much point to (theoretically) saving a few megabytes of RAM when you're pulling in twice as much unused code. But there is. The unused code is still shared.

juliangoldsmith 8y ago
That might make a marginal difference if you have large libraries that are used in a large number of applications that run concurrently. Otherwise, the sharing is completely pointless.
caf 8y ago
...and the libraries are typically demand-paged as well, so the truly unused stuff isn't even resident.
- juliangoldsmith 8y ago
  That would assume that used and unused code aren't mixed within pages.