The modern packager’s security nightmare
The day I stop static linking is the day I can compile on one distro and ship to many without worrying about users reporting loader errors. That day is not today.<p>Until then, I&#x27;ll keep doing it, because it saves me time and money.<p>I don&#x27;t really buy that dynamic linking all the things is such a boon to security. But I&#x27;ll link to this: <a href="https:&#x2F;&#x2F;drewdevault.com&#x2F;dynlib" rel="nofollow">https:&#x2F;&#x2F;drewdevault.com&#x2F;dynlib</a><p>&gt;  Not including libc, the only libraries which had &quot;critical&quot; or &quot;high&quot; severity vulnerabilities in 2019 which affected over 100 binaries on my system were dbus, gnutls, cairo, libssh2, and curl. 265 binaries were affected by the rest.<p>&gt; The total download cost to upgrade all binaries on my system which were affected by CVEs in 2019 is 3.8 GiB. This is reduced to 1.0 GiB if you eliminate glibc.<p>&gt; It is also unknown if any of these vulnerabilities would have been introduced after the last build date for a given statically linked binary; if so that binary would not need to be updated. Many vulnerabilities are also limited to a specific code path or use-case, and binaries which do not invoke that code path in their dependencies will not be affected. A process to ascertain this information in the wake of a vulnerability could be automated.