4 ms·

A common argument around dynamic linking is that it makes security updates easier. This seems like a weak argument as an update could easily introduce new bugs

by bhawks 6y ago

A common argument around dynamic linking is that it makes security updates easier. This seems like a weak argument as an update could easily introduce new bugs with a security impact as well. Static linking gives a tested, known good executable. Running untested combos of libraries gives me some anxiety.

StreamBright 6y ago
I think it is very hard to quantify problem. In my experience once you have a security policy about updates it is equally easy to update statically and dynamically linked software. The real problem is that most companies do not care. On the other hand, if many application are running in Docker today does it matter if that app has static or dynamic linking?
redis_mlc 6y ago
> Running untested combos of libraries gives me some anxiety. It should, especially with multi-threaded code. (Half of MySQL AB's support calls at one time were user-built binaries. Building things yourself skips the vendor's QA process. For new grads, it used to be a thing of pride to build your own database, web and mail servers on linux, and nobody valued QA at the time.)
strictfp 6y ago
The argument is made on a system level, not on a single binary level. Given many dynamically linked binaries, it's relatively easy to patch say OpenSSL on a system. If all binaries are statically linked, you need to relink all binaries and push new versions of each one.
choeger 6y ago
It's not really about static vs. dynamic linking IMO. The point with ld is that the distribution has one central point for linking. If static linking with go, rust, C, etc. would work in a similar fashion, each executable could be shipped with a "re-link" script and the distribution could again provide security patches efficiently. But when linking happens in some poorly maintained script, inside a custom build systen, written in two or more languages, running inside a docker container, executed by some year-old CI integration, patching security issues becomes impossible.

by bhawks 6y ago

StreamBright 6y ago

I think it is very hard to quantify problem. In my experience once you have a security policy about updates it is equally easy to update statically and dynamically linked software. The real problem is that most companies do not care. On the other hand, if many application are running in Docker today does it matter if that app has static or dynamic linking?

redis_mlc 6y ago

> Running untested combos of libraries gives me some anxiety. It should, especially with multi-threaded code. (Half of MySQL AB's support calls at one time were user-built binaries. Building things yourself skips the vendor's QA process. For new grads, it used to be a thing of pride to build your own database, web and mail servers on linux, and nobody valued QA at the time.)

strictfp 6y ago

The argument is made on a system level, not on a single binary level. Given many dynamically linked binaries, it's relatively easy to patch say OpenSSL on a system. If all binaries are statically linked, you need to relink all binaries and push new versions of each one.

choeger 6y ago

It's not really about static vs. dynamic linking IMO. The point with ld is that the distribution has one central point for linking. If static linking with go, rust, C, etc. would work in a similar fashion, each executable could be shipped with a "re-link" script and the distribution could again provide security patches efficiently. But when linking happens in some poorly maintained script, inside a custom build systen, written in two or more languages, running inside a docker container, executed by some year-old CI integration, patching security issues becomes impossible.