Hacker News Reader

Comment by cm3 | Hacker News Reader

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.

View on HN

> 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.

> 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.

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 :).

Reply on news.ycombinator.com