Of the 14 CVE reports, only 7 applied to LibreSSL. None of the "High" severity applied:

http://marc.info/?l=openbsd-tech&m=142677518515567&w=2

By severity, 4 of 9 of the "Moderate", and 1 of 3 "Low" were already fixed in LibreSSL, by my quick count.

Is there an update anywhere about how close libressl is to "prime time"?

LibreSSL is ready for prime time. It is the default SSL library on OpenBSD since version 5.6 [1], which was released on November, 1st 2014. Since then, more cleanup went in, and they developed libtls which is a new TLS API.

The latter is also included in several OpenBSD projects (OpenSMTPD, relayd, httpd).

The goal of libtls is to provide a sane API to develop new applications needing TLS. The problem with OpenSSL's API is that it exposes too much, and it's extremely easy to shoot yourself in the foot.

If you want to know more regarding LibreSSL, I recommend reading these:

http://www.openbsd.org/papers/bsdcan14-libressl/ http://www.openbsd.org/papers/eurobsdcon2014-libressl.html

Despite what the URL suggests, these are not papers but presentations at BSD related conferences. You might be able to find recordings of them on YouTube.

[1] http://www.openbsd.org/56.html

So, I am pretty proficient in these things, but I don't consider myself competent to declare it ready by code audit. I like the Google support, and I like the OpenBSD adoption. But since I am not running OpenBSD, I'd really like to see it make it into my distro's upstream by some community process. Endless ink and bits have gone into talking about 'cruft' in code that provokes big refactorings, when the what was considered cruft ends up being quite meaningful to correct and/or stability. To summarize - I'm with the gp post, I'm not convinced it's ready for primetime, either: it's stepping into giant shoes and has a very short track record.

Actually, libressl is practical drop-in replacement of openssl if you use only sane parts of openssl's functionality.

Biggest problem now is some upstream softwares still depends on insanity Openbsd devs nuked away, like RAND_egd() or won't admit that libressl actually exist :)

(https://devsonacid.wordpress.com/2014/07/12/how-compatible-i..., https://blog.hboeck.de/archives/851-LibreSSL-on-Gentoo.html)

But situation is changing as more and more upstream developers abandon those APIs : https://github.com/gentoo/libressl/blob/master/README.md

And I guess this is cool thing about libressl: even if it fails to replace openssl for real good, it is still forcing others to advance toward right direction (remember the linux fork fuss last year? You can disagree with me but I myself consider it linux's 'fault' not to have consistent mechanism of extracting entropy....it doesn't have to be arc4random but it could have been better in the first place if this IMO)

I don't know why they didn't keep RAND_egd() in, but just implement it as:

  int RAND_egd(const char *path)
  {
      return -1;
  }

Yeah, that's the quickest fix for some softwares but OpenBSD devs can be really 'uncompromising' when they consider some features broken/dangerous. That's how they managed to have "2 remote holes in default install" for decades I guess :/

http://marc.info/?l=openbsd-tech&m=140512043210089&w=2

https://www.mail-archive.com/linux-crypto%40vger.kernel.org/...

That's not really an answer, though, is it? Because the feature is just as gone, it's just that it still remains API-compatible.

Here's the link to debian's wnpp bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513

Thanks for that; looks promising (even if these things take time /-). Does anyone know how viable it would be to create a shim for the new libtls-api for gnutls/nss? A shim for openssl isn't really all that interesting; hopefully that thing will die a horrible, slow death... and with some luck libressl can be the thing to nudge a better api into wider use.

Hm... this was posted on hn a while back, but didn't receive any comments. An implantation of part of the libtls (client) api by piping to the tls implementation in go's standard lib. If it really is this abstract, it should be possible to do this for both GnuTLS and NSS?:

http://www.tedunangst.com/flak/post/goreSSL

Well, OpenBSD is one thing, but LibreSSL is about more than being OpenBSD's SSL implementation, right? If I'm running ubuntu or debian, at what point can I just say "fuck it, uninstalling openssl and switching to libressl as a drop-in replacement" without having to run through hours of hacky shimming or whatever and/or making various compromises at every turn?

Like other OpenBSD projects, it is developped against the OpenBSD tree and the 'portability goo' is added later on. It is the same case with libressl. There is GitHub repository: https://github.com/libressl-portable/ and release tarballs: http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/

Keep in mind that LibreSSL is not a rewrite but a fork. Assuming your software uses the sane parts of the OpenSSL API, there shouldn't be any problems. If they use some interface that was deemed unsafe, well then I'd say it's time to fix the software (if the source is available). As far as ubuntu/debian are concerned, I'd say it's only a matter of time before it is available in the main repositories.

Well, it's in OpenBSD, so now?

And an important note from http://undeadly.org/cgi?action=article&sid=20150319145126

> The OpenSSL project provided information and patches to the LibreSSL project in advance of the announcements.

So 4 out of 14 needed fixing in -current, while the rest were either already fixed or not relevant to libressl. It would be interesting to know who fixed the ones that were fixed already, and when.

I guess that most of these were "fixed" by simply throwing away lots of garbage code from OpenSSL during the evolution of LibreSSL.

Don't undersell that man, priority zero in security is reducing the threat surface.

There are no quotation marks about it; it still counts.

You may be interested in the experience report of Ted Unangst about fixing security issues in OpenBSD:

http://www.tedunangst.com/flak/post/making-security-sausage