Having to recompile all applications and libraries to remove the potential crypto bug is a pretty scary bug :-/
If you're using Go, you should already have the infrastructure to do this. Everything we have gets rebuilt for each go release anyway, so this is no different, just a little more immediate.
Unless you're using packages in an APT or Yum repo. You instead get to wait for packages to come downstream, almost certainly not in anything approaching synchronicity. Awesome.
We got away from statically linked monoliths for a reason.
It's been particularly bad in the past for things like nginx, where we've known about memory corruption bugs for multiple days and had clients who were incapable of patching because they only had infrastructure for downloading packages.
You should have tools in place to build, from source, anything that might be a significant security issue.
And while I 100% agree about the optimal case, in practical terms you're going to see a lot better turnaround from the maintainers of Debian's OpenSSL than, say, the third-party Docker repo. A sane system not reliant on static linking 'til the cows come home is not a cure-all, but it's better than the Go situation, and is a part of why I'm super not thrilled with Go-as-infrastructure. (Go-as-app, whatever, people take that problem on themselves.)
Imagine the nightmare of having to hunt tens of shared libraries versions, and even have to re-build them and patch them with the correct version of the language/apis so that they continue to work.
That's all well and good, but that's just you. Real systems often get messed with multiple copies/versions of shared libraries. Also known as dll-hell in Windows. In Java land you could easily end up with 20 versions of some jars just as easily, all installed locally by maven and needed by this or that lib/framework/etc.
>Or rather, I do, but that's because it's my job, and I'm actually good at my job.
Citation needed.
We're talking about businesses deploying multiple server apps and such. Neither Java nor .NET shops for example rely on "OS packages" for their server dependencies when it comes to Jars, dlls, etc.
Then you were off topic, since we were discussing Golang packages for deployment, which aren't userland packages either. But whatever.
>If you're deploying a Java application, everything should be coming out of Maven (and thus avoid any sort of shared library hell) in the first place, no?
You still get multiple copies of jars. And you still need to replace them. And you still might have older projects that need particular versions of a jar that you need to update somehow in case such a long-reaching issue is discovered (and upstream might not do that at all).
But it's probably not so trivial to hunt down every single old binary on every system. There's also a continuous risk that you may receive old binaries from third parties in the future.
For example, gitlab has started to ship a component written in Go in recent versions. Things like these are easy to forget about.