> a better approach would be for everyone to try to move to what's in BoringSSL
Google don't recommend you do this.
https://boringssl.googlesource.com/boringssl/
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general
use, as OpenSSL is. We don't recommend that third parties depend upon it.
LibreSSL has taken fixes from BoringSSL but it has the aim of maintaining API compatibility to the point where most applications using OpenSSL should "just work" for the most part. I've not tried building against BoringSSL but form reading their documentation it seems like the API is very much a moving target.
That's right, but I know several project maintainers who are looking moving to it because BoringSSL's scope is smaller and is sufficient for their projects' needs. That's why I think the BoringSSL's API status will evolve with time. And Ring is based on it, so...
Then there's ocaml-tls which aims to provide a drop-in implementation of the OpenSSL API too.
We're finally seeing much activibity, and in that sense, I'm glad that Heartbleed happened, but it should have been earlier :).
If we still stay with C, Ring would be a good replacement, which is partially/primarily written in Rust.
That said, LibreSSL's TLS abstractions look like a welcome improvement if you need a C API.