Comment by blibble

> If someone meant to engineer a codebase to hide subtle bugs which might be remotely exploitable, leak state, behave unexpectedly at runtime, or all of the above, the code would look like this.

I wonder who could possibly be incentivized to make the cryptography package used by most of the worlds computers and communications networks full of subtly exploitable hard to find bugs. Surely everyone would want such a key piece of technology to be air tight and easy to debug

But also: surely a technology developed in a highly adversarial environment would be easy to maintain and keep understandable. You definitely would have no reason to play whackamole with random stuff as it arises

Another great example from tedunangst's excellent presentation "LibreSSL more than 30 days later".

https://youtu.be/WFMYeMNCcSY&t=1024

Teaser: "It's like throw a rock, you're gonna hit something... I pointed people in the wrong direction, and they still found a bug".

I expected much worse to be honest. Vim’s inline #ifdef hell is on a whole other level. Look at this nightmare to convince yourself: https://geoff.greer.fm/vim/#realwaitforchar

See also The State of OpenSSL for pyca/cryptography

https://news.ycombinator.com/item?id=46624352

> Finally, taking an OpenSSL public API and attempting to trace the implementation to see how it is implemented has become an exercise in self-flagellation. Being able to read the source to understand how something works is important both as part of self-improvement in software engineering, but also because as sophisticated consumers there are inevitably things about how an implementation works that aren’t documented, and reading the source gives you ground truth. The number of indirect calls, optional paths, #ifdef, and other obstacles to comprehension is astounding. We cannot overstate the extent to which just reading the OpenSSL source code has become miserable — in a way that both wasn’t true previously, and isn’t true in LibreSSL, BoringSSL, or AWS-LC.

Also,

> OpenSSL’s CI is exceptionally flaky, and the OpenSSL project has grown to tolerate this flakiness, which masks serious bugs. OpenSSL 3.0.4 contained a critical buffer overflow in the RSA implementation on AVX-512-capable CPUs. This bug was actually caught by CI — but because the crash only occurred when the CI runner happened to have an AVX-512 CPU (not all did), the failures were apparently dismissed as flakiness. Three years later, the project still merges code with failing tests: the day we prepared our conference slides, five of ten recent commits had failing CI checks, and the day before we delivered the talk, every single commit had failing cross-compilation builds.

Even bugs caught by CI get ignored and end up in releases.

> If someone meant to engineer a codebase to hide subtle bugs which might be remotely exploitable, leak state, behave unexpectedly at runtime, or all of the above, the code would look like this.

I'd wager if someone did that the codebase would look better than OpenSSLs

The codebase designed to hide bug would look just good enough that rewriting it doesn't seem worth it.

OpenSSL is so bad that looking at it there is just desire to rip parts straight out and replace them, and frankly only fear-mongering around writing security code kept people from doing just that and only after heartbleed the forks started to try. And that would also get rid of any hidden exploit.

There is a reason AWS created their own TLS library.

The longer I develop software, the more I realize just how awful most software engineering it.

Is it still a critical piece? I thought most everyone migrated to libressl or boringssl after the heartbleed fiasco and serious people took a look at OpenSSL and started to understand the horror show that is the codebase and also development practices that clearly have not gotten better, if not gotten even worse.

AWS actually has two libraries they use instead: s2n and aws-lc https://github.com/aws/s2n-tls https://github.com/aws/aws-lc

Security certifications are one reason. OpenSSL maintains a module for FIPS compliance, which includes an entire boatload of weak and broken algorithms nobody else bothers with.

Because as horrible as the OpenSSL code is, the best available clean implementation would mean using a language that's weird and French.

For one thing, "C/C++" is not a thing. If you see C-like C++, that is C.

Part of OpenSSL's incomprehensibility is that it is not C++ and therefore lacks automatic memory management. Because it doesn't have built-in allocation and initialization, it is filled with BLAH_grunk_new and QVQ_hurrr_init. "new" and "init" semantics vary between modules because it's all ad hoc. Sometimes callees deallocate their arguments.

The only reason it needs module prefixes like BLAH and QVQ and DERP is that again it is not C++ and lacks namespaces. To readers, this is just visual noise. Sometimes a function has the same name with a different module, and compatible function signature, so it's possible to accidentally call the wrong one.