Comment by cookiengineer
9 hours ago
The reason I value Go so much is because you have a fat dependency free binary that's just a bunch of syscalls when you use CGO_ENABLED=0.
Combine that with a minimal docker container and you don't even need a shell or anything but the kernel in those images.
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.
7 replies →
Yes, you can have docker container images that only contain the actual binary you want to run.
But if you are using a VM, you don't even need the Linux kernel: some systems let you compiler your program to run directly on the hypervisor.
See eg https://github.com/hermit-os/hermit-rs or https://mirage.io/