4 ms·
Assuming we stay with a library written in C, a better approach would be for everyone to try to move to what's in BoringSSL, which deliberately removed most stu
by cm3 10y ago
Assuming we stay with a library written in C, a better approach would be for everyone to try to move to what's in BoringSSL, which deliberately removed most stuff, more than LibreSSL.
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.
- gbrown_ 10y ago> 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/ 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. > which deliberately removed most stuff, more than LibreSSL 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.
- cm3 10y agoThat'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 :).