If you&#x27;re looking for a guarantee - very few non-trivial programs are <i>provably</i> correct.  Heck, most of the time what comes out of the compiler isn&#x27;t even exactly what you put in - everyone knows -O3 can do some weird stuff, and that&#x27;s A Bad Thing in certain kinds of software.  We&#x27;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&#x27;m not involved in it but I find that niche to be really interesting, along with reproducible builds.  It&#x27;s crazy that nobody bothered with simple stuff like &quot;seeding the PRNG for stochastic optimizers&quot;.  You&#x27;d have thought they&#x27;d just pick a reasonable default.<p>So given that we live in a world of imperfect code, it&#x27;s a question of what&#x27;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&#x2F;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.<p>The OpenBSD folks are happy enough with LibreSSL that they released it with OpenBSD 5.6, which is good enough for me.  I&#x27;m sure there&#x27;s some esoteric vulnerabilities lurking and maybe the cleanup introduced a few new ones, that&#x27;s just the nature of non-trivial software.  But in the big picture I just can&#x27;t see it as being any <i>more</i> vulnerable than OpenSSL, and that seems to have been borne out in their respective track records recently.