Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: