You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: