BoringSSL Support

[benbrittain]

BoringSSL

I'd like to investigate adding BoringSSL support to the rust-openssl crate. BoringSSL is a fork of OpenSSL that's designed to be harder to use incorrectly, but it also lacks the same backwards compatibility guarantees and has an unstable API/ABI. Some companies use BoringSSL exclusively (e.g. Google or Cloudflare) and since rust-openssl is the de facto way to interface with TLS/SSL in the rust ecosystem it would be nice to have support through this crate.

There exists some prior art in the rust ecosystem, notably boring and mundane.

Constraints

• Minimal cfg additions to rust-openssl
  • rust-openssl already contains many cfgs for various openssl versions. Boringssl support should be at most minimally more invasive.
  • Should not make upgrading rust-openssl harder.
• No way for ABI drift to occur with boringssl
  • This is a scary problem because a subtle ABI violation could introduce a security hole.
  • The lack of stability in boringssl means that copy/paste headers isn't a viable solution.
• Less relevant to rust-openssl, but we should also avoid putting an undue burden on the BoringSSL maintainers.

Implementation

I'd like to solve this in a more integrated way by adding "*-sys" binding generation support into the build system of boringssl directly. This will guarantee the ABI doesn't drift from top-of-tree. The primary maintainers of BoringSSL have expressed willingness to use this approach. As much as possible should be generated by bindgen directly, as opposed to how openssl-sys handrolls a chunk of the bindings.

We'll likely want a boringssl-sys/boringssl-source setup similar to openssl-sys however so that we can provide a quick and easy static linking solution for people who desire it.

I'm in the middle of a quick prototype of this at the moment and it seems pretty tractable. Concerns and/or thoughts?

[sfackler]

That seems reasonble to me at a high level. I'd like to keep bindgen out of the default dependency graph of openssl-sys (pulling it in as an optional feature is fine).

[sfackler]

Now that OpenSSL 3.0.0 is out, I'm going to start working on a new major version release of the openssl crate (openssl-sys will be staying at 0.9). If there are API breaks that would help with the BoringSSL integration, let me know!

[tomleavy]

This would be helpful for me as well. I was thinking about contributing support for AWS-LC which is a fork of BoringSSL. Wasn't sure where to start with that since I'm not yet familiar with how openssl-sys finds the library etc

[photex]

I'm using BoringSSL as part of a large bazel workspace and would really appreciate being able to re-use my efforts there in the rust portion of our codebase. Once we started trying to seal off the build from host environments (only use specific toolchains etc) OpenSSL has been the biggest issue so far from an integration point of view.

[sfackler]

FYI, I have started working on a Cargo feature to use bindgen to replace (at least most of) the handwritten openssl-sys bindings: #1573

[alex]

BoringSSL now comes with code to generate bindings: https://boringssl.googlesource.com/boringssl/+/8d8d8f3ea727d52df86db03e3a75008b43be7dae