review of the OpenSSL codebase hasn't always been easy (apparently, I have not tried to read the code myself).
Depends on the part, the ASN1 parser stuff is and was extremely difficult to review. The basic cryptographic code OTOH is mostly fine, readability wise-- though there are a lot of different platform specific optimizations and different cryptosystems in there, so a lot of work to review.
A lot of the "readability" fixes that they did do were just running the entirely codebase through an autoformatter. I think this was a complete and utter disaster for reviewability-- it caused them to issue a 400k line diff (which they also mixed in with security changes). Presumably they were also hiding undisclosed fixes in that massive change, but-- perhaps they also hid new vulnerabilities. It's completely impractical to review that, so only history will tell.
If your "readability" problem was one that could be solved by mechanically adjusting formatting, you could have done that locally without any fear that something naughty was slipped in.
OpenSSL is used by various industries who require that it can be compiled for use on their old hardware architectures (possibly using old operating systems in some cases).
Libsecp256k1 should be roughly equally portable (in fact, in some respects it is more portable just because it's smaller and does less-- so any adjustments needed for a weird platform would be smaller). I test libsecp256k1 back to GCC 2.95 (from 2001, which is extremely old by modern standards-- though OpenSSL originally worked with older toolchains I have no idea if they continue to test with anything that old). Libsecp256k1's tests also pass when compiled to a 16-bit DOS executable (though a couple of changes are needed to the tests to keep them from exhausting the stacks).
I don't see much point in open source code that is unreadable by anyone except those who wrote it, it's very similar to the proposition of proprietary binaries to me
Well there are orders of magnitude, even the worst parts of the OpenSSL code are much more reviewable than a binary.
Meanwhile, there are several SSL implementations available, some more widely used and tested than others (and each targeting various different uses). It's not the easiest change to make to a system, it's really best done to a minimal OS installation before any other software is installed (as so much software depends on SSL).
It's always good to be a bit wary when someone is pitching that their reimplementation solves all the problems unsolved by the Standard Solution-- often it means that the reimplementation didn't understand the entire problem domain (or they did and are intentionally ignoring a big chunk).
Some of OpenSSL's awfulness is self-inflicted legacy baggage, but a good chunk is simply because of what it's being asked to do. Some of OpenSSL's flaws also appear to stem from interface decisions that cause callers to introduce flaws, -- and the drop in OpenSSL alternatives preserve those interfaces for compatibility.
To the extent that some of these alternatives have dropped support for older standards or weird platforms they might also have improved on the "being asked to do" front, ... if your usage is okay with those limitations. As far as legacy baggage goes-- we remain in a state where virtually none of the folklore advice about code-smell has been backed by rigorous scientific study. Programmers are often _extremely_ opinionated about "bad code" yet there are relatively few examples of widely code style differences which are uncontroversially and unambiguous causes of defect-- often complaints about "bad code" really just means "not my preferred style". In so far as an alternative is only an improvement with respect to some person(s) subjective impression of "bad code" I am extremely wary, the hardening that software gets from widespread use is commonly and easily undervalued-- if I had to pick between a widely deployed solutions with well understood weaknesses vs something new which is supposed to be subjectively better, I'd pick the former every time. It seems the market agrees: OpenSSL is extremely widely used compared to some of the new alternatives.
For Libsecp256k1 in Bitcoin we switched not because subjective "code smell" sorts of reasons but because of more objective criteria like:
* Designed for consensus consistency: OpenSSL was provably not consensus consistent and was continuing to actively make changes which damaged consistency with little to no consideration of this class of concern or even adequate disclosure of the changes.
* Free of timing sidechannel secret leaks for secp256k1: OpenSSL's code for this curve wasn't even trying to be constant time. Ours was.
* Formal validation: Libsecp256k1 is partially formally validated, none of the parts of OpenSSL we were using are, to the best of my knowledge.
* Speed: libsecp256k1 was 5-7x faster than OpenSSL.
* Extensive testing: libsecp256k1 had many kinds of tests openssl didn't have at all, and has more now-- tests in libsecp256k1 found serious bugs in openssl, etc.
And sure I think the libsecp256k1 is a lot more readable and maintainable than the relevant code in openssl, and I hope those differences also help lower defect rates... but its all the items above that made it the right thing for Bitcoin to use vs something with a much longer track record, and not some formatting stuff which is inherently pretty subjective and may not actually make the software better.
