Ugh, another example of why conditional compilation is such a bad idea. I know, I know, sometimes it's inevitable. But if you're going to use it, you'd better be ready to set up a build farm that regularly compiles your code with every possible permutation of compiler flags, otherwise your code is guaranteed to break in unexpected ways.
The LibreSSL solution is the correct one here: if your code is old and unused, just delete it ffs. The argument that "we might still need it in the future!" is such a lame one. No you don't, and even if you do it'll be easier to just rewrite it than to try and make years-old code work in a modern environment. In the meantime you've only succeeded at cluttering your code with garbage that has no relevance whatsoever.
It's remarkably hard to find any recent discussions if libressl is ready for production. A comparison on https://en.wikipedia.org/wiki/LibreSSL seems to indicate libressl is less vulnerable.
If you're looking for a guarantee - very few non-trivial programs are provably correct. Heck, most of the time what comes out of the compiler isn't even exactly what you put in - everyone knows -O3 can do some weird stuff, and that's A Bad Thing in certain kinds of software. We're only just starting to break that ground now with verifying compilers like CompCert (which can output a set of mathematical proofs that your program is correct for the given input). I'm not involved in it but I find that niche to be really interesting, along with reproducible builds. It's crazy that nobody bothered with simple stuff like "seeding the PRNG for stochastic optimizers". You'd have thought they'd just pick a reasonable default.
So given that we live in a world of imperfect code, it's a question of what's least-bad. OpenSSL is known to be a horrific mess of crufty under-maintained code, which is a big part of why it keeps having major security breaches. Like this article points out - nobody has bothered to compile this option for more than a decade. Options lead to internal complexity which leads to crap code that nobody can/will maintain, which is the wrong path for security-critical software. If nobody uses it then get rid of it - if someone wants it they can dig it out of revision history.
The OpenBSD folks are happy enough with LibreSSL that they released it with OpenBSD 5.6, which is good enough for me. I'm sure there's some esoteric vulnerabilities lurking and maybe the cleanup introduced a few new ones, that's just the nature of non-trivial software. But in the big picture I just can't see it as being any more vulnerable than OpenSSL, and that seems to have been borne out in their respective track records recently.
I'm not naive. All software has bugs. Only thing that works out the bugs is battle testing. I was just wondering if LibreSSL was battle tested enough to use in production.
Battle testing finds uncommon bugs. This is orthogonal to whether these bugs are security-relevant.
See, for example, shellshock, which was in a piece of software that's been battletested by most people who use a command-line for the past, oh, twenty years or so.
Whether or not the developers actually know what they're doing with respect to writing secure software in the language of the project and are sufficiently OCD in their process to catch most mistakes before they reach production is very, very much more important than "battle tested for X number of years".
I started testing nginx compiled against LibreSSL from before portable was official[0].
If your goal is security, as far as I'm concerned it's met that goal since day one. If the goal is stability, the slimmer codebase is certainly no less stable than OpenSSL.
There were however, several occasions places where code didn't compile for various reasons. Some were fixed by nginx, and some were fixed with PRs I sent LibreSSL. Key to this is that there were situations where newer releases of LibreSSL broke my build process.
If you were on a project less ubiquitous than nginx, you may find that sort of hacking a waste of time.
If you have the resources to use it, it's posts like this that strongly turn me in the direction of LibreSSL.
1) 11 years. The code in question was 11 years old. Another example not to rely on "given enough eyeballs, all bugs are shallow". 11 freakin years.
2) Security off by default is yet another example indicating how security receives lower priority - in a library whose main aim is to secure data transport no less!
It all adds up to security debt - at some point it will be paid.
The random data that was used to initalize the PRNG was removed as it was causing a linting error and only the PID was used meaning there were only 32768 (2^15) initial states that the PRNG would be seeded with.
Yes I remembered this one, and this resulted in the SSH keys being weakened. So ... it is the same incident.
OpenBSD could forgot one day. As if 50 core devs pretending to know their jobs could do better than 10000 devs with tremenduous amounts of guidelines and administrative rules and a fair amount of political commissars.
Weakened? It meant it would only generate a couple of thousand keys, that's not weakened, that means security was killed completely. And it was in there for a couple of years. All in all a total fiasco and legendary for very good reasons.
Trying to paper over it and pretending it was no big deal is the best way to ensure that similar things will happen again.
The LibreSSL solution is the correct one here: if your code is old and unused, just delete it ffs. The argument that "we might still need it in the future!" is such a lame one. No you don't, and even if you do it'll be easier to just rewrite it than to try and make years-old code work in a modern environment. In the meantime you've only succeeded at cluttering your code with garbage that has no relevance whatsoever.