[throwaway5752]

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.

[masamune__]

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)

[caf]

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;
  }

[masamune__]

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

[caf]

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.

[kpcyrd]

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

[e12e]

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.

[e12e]

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