1. 6
  1.  

  2. 1

    I’ve already mentioned this elsewhere, but I think shared libraries is the best default option. You’re trading security vs stability, and I would prefer a secure, broken program over a stable, possibly insecure program.

    I think defaulting to static linking is fine for what Go is currently used for (in house sites and services), but it’s bad for the FOSS ecosystem. For example, if I use a Go binary that is linked against a vulnerable library, I have to hope that the developer is following CVE reports for all dependencies. When a new security exploit is discovered, the developer has to recompile against the updated libraries, repackage, and push the new package to each distro.

    What was originally a single responsibility for monitoring security issues is now distributed among all the maintainers and developers.

    1. 1

      Since when do developers push binaries to distros? It seems like packagers should have a flag than be easily set that says “statically compiled, recompile when a dependency changes.”

      1. 2

        packagers should have a flag than be easily set that says “statically compiled, recompile when a dependency changes.”

        Perhaps in an ideal world, but that’s not how Linux currently works. A CVE was opened up against a software I maintain, and the RedHat maintainer contacted me to fix it. I patched it and he backported it the version in RedHat’s repos. The (minor) vulnerability still exists in Debian and Ubuntu. If this was a static library it’d be no different, the onus is on the developer to update the software.