4 ms·

Packaging would be simpler, but you probably have to update the whole OS and all your installed apps when a security update for a common library is released.

• taeric 4y ago
  Not wrong; at the same time, I'm becoming less convinced this is relevant. Seems many security updates have to do with code paths that are not used in a large number of applications. Similarly, many of them are fixes on features that even more apps didn't want/need, but they got when they updated to get the last round of security fixes. :( The docker world is a neat example of this. The stories of ${absurdly high percent} of containers having vulnerabilities only gets to claim that because of "unpatched libraries." If you reduce it to the number of containers with exploitable vulnerabilities, it is still non-zero, but not nearly as high.
  • nightfly 4y ago
    The problem is having to wait for all those applications to push updates when a vulnerability is found in a common library
    • taeric 4y ago
      That is the thing, though. For most applications, those vulnerabilities in a common library are not relevant. That is what I was talking about in saying that it is in code that isn't used by them. You are, of course, right that it has the possibility of happening. But by and large, it doesn't happen there any more often than it does in the dynamically linked cases. And, by and large, the dynamically linked cases are often a lot more complicated to deploy. (Granted, deployment for either should be doable nowadays.) The dream, of course, is you just patch the library and call it a day. The reality seems to usually be a circus check on every application that you have deployed to see if they are impacted anyway.
    • initplus 4y ago
      The solution to this is to make the build process as simple as possible. Then pushing updates has a much lower maintenance cost. I can be confident I will be able to build >90% of go programs by cloning the repo and calling go build.