Boulder without CGO
Background
This isn't planned anytime soon, but something that was on my mind so I thought I'd record some notes.
It would be nice to be able to build Boulder without CGO. That would facilitate easier cross-compilation at least, such as building on arm64 laptops, or deploying binaries from GHA to arm64 cloud instances
I believe the only place we use CGO is for PKCS#11 to talk to the HSM.
Options
P11-kit remoting
We switch to some other standard interface for talking to HSMs. For example, the p11-kit "remoting" protocol for PKCS11 is used in AWS Nitro Enclaves as its interface, and we could use the p11-kit server to wrap our vendor's pkcs11 library. I think there may be other options here too
Subprocess
Use a process-based plugin model to isolate the C_GO code. I think something like Hashicorp's go-plugin could be either used, or serve as a model. Approximately, this means boulder_ca manages a subprocess that handles the CGO parts. All of the configuration for Boulder stays the same, probably just with the addition of a path to the plugin process. go-plugin executes a subprocess and communicates with it over grpc via the subprocess' stdin/stdout, eliminating the need to worry about anything like unix socket paths, permissions, and so on. Or even one-execution-per-signing, but that sounds inefficient.
Sidecar
Pull the core of signing out into a minimal, independent sidecar service. Could be grpc-over-unix socket or similar. It handles all the details of PKCS11 configuration, etc. This does mean we need to be careful about permissions, to ensure only boulder-ca can access the socket. However, this does mean we can do things like run separate containers for the HSM/PKCS11 code, which may be advantageous for other reasons as well.
boulder-ca with CGO
Split all of boulder-ca into its own binary built with CGO, and the rest of boulder can be built without CGO.
Performance
Because we run dedicated, isolated instances for boulder-ca, we have plenty of memory and CPU available, so latency is the only performance concern.