Comment by akoboldfrying
10 hours ago
Why would statically linking a library reduce the number of vulnerabilities in it?
AFAICT, static linking just means the set of vulnerabilities you get landed with won't change over time.
10 hours ago
Why would statically linking a library reduce the number of vulnerabilities in it?
AFAICT, static linking just means the set of vulnerabilities you get landed with won't change over time.
> Why would statically linking a library reduce the number of vulnerabilities in it?
I use pure go implementations only, and that implies that there's no statically linked C ABI in my binaries. That's what disabling CGO means.
What I mean is: There will be bugs* in that pure Go implementation, and static linking means you're baking them in forever. Why is this preferable to dynamic linking?
* It's likely that C implementations will have bugs related to dynamic memory allocation that are absent from the Go implementation, because Go is GCed while C is not. But it would be very surprising if there were no bugs at all in the Go implementation.
They're prioritizing memory corruption vulnerabilities, is the point of going to extremes to ensure there's no compiled C in their binaries.
6 replies →