It seems that py/cryptography's thoughts about OpenSSL (https://cryptography.io/en/latest/statements/state-of-openssl/) are doing the rounds at the moment.

I've not touched OpenSSL directly in a long time. In fact, it appears that the 10-year anniversary of that (https://www.imperialviolet.org/2015/10/17/boringssl.html) passed by a few months ago!

So I've no direct comments on the piece but, a long time ago, I was in the position where I was landing changes in both OpenSSL and NSS (Mozilla's TLS library). OpenSSL was somewhat famous for having bad code. And, indeed, if you looked at it back then the functions were full of single-letter variable names with pointer arithmetic everywhere and context-free, somewhat scary comments. It wasn't outside the norm for 1990s C code, but I understand why people recoiled.

In contrast, if you looked at NSS code, it looked good! Consistent formatting (before clang-format), good naming, good comments.

But NSS had a PKCS#11 abstraction layer and, even after years, I never could understand how the control flow worked there. I would have to single-step in gdb every time to figure out where an operation grounded out into actual code. I was reminded of that when reading py/cryptography's descriptions of OpenSSL 3.0.

I had a pet theory at the time that, because OpenSSL was repulsive on the surface, it inhibited people enough that they couldn't add much deeper complexity. But NSS, with its invitingly clean-looking code, was understandable and then people had enough capacity left over to add deeper complexity.

There might be something to it, although you shouldn't discount the fact that entities who are willing to fund cryptography libraries often have demands that are contrary to clean code. Things like FIPS compliance and compatibility with a zoo of different accelerators and bespoke needs.

So rather it might have been that old OpenSSL was old OpenSSL because it was mostly unfunded. That meant that it looked pretty ragged, but also there weren't so many demands in tension with good design.

NSS was funded by interests that really cared about PKCS#11 compatibility so that you could use a super-expensive, certified-everything HSM with it. When OpenSSL got shocked into switching to a higher-funding model, that brought lots of those same sorts of competing interests, and then the incentives pointed towards adding slow, impenetrable layers of abstraction all over.