--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/89720e28-98af-46ee-881f-0ecab9ba9b4a%40googlegroups.com.
It highly depends on how you're building gRPC and / or getting your binaries.
If you're building through CMake (which I guess is what your "CM" means, maybe?), then you can specify what you are doing exactly:When using cmake, you can either build BoringSSL from a cmake module, or import OpenSSL as a package, using the cmake variable "gRPC_SSL_PROVIDER". That file should be sort of self-documenting, but there is a few more info here: https://github.com/grpc/grpc/blob/master/doc/ssl-performance.md
On Mon, Jan 27, 2020 at 11:10 AM Bill Fanelli <gsa.bil...@gmail.com> wrote:
I am trying to determine if gRPD supports FIPS 140 validated encryption. For our organization, as long as the underlying cryptographic modules (CMs) are FIPS 140 validated, then we are good to go. From my (brief) survey of the GitHub site, it appears that gRPC has BoringSSL CM embedded. BoringSSL is FIPS validated.--Question: Can anyone point me to where the use of BoringSSL is documented? Hopefully I will be able to determine how the BoringSSL CM is used (or can be configured to be used).All other insights on this topic also welcome.
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grp...@googlegroups.com.