After Heartbleed, BSD developers forked OpenSSL and "cleansed" it. They removed ridiculous amounts of unmaintained legacy code, rewrote much of the rest, and tightened the security.
The old code was littered with conditional compilation macros that made it virtually impossible to reason about or test. There are just too many forks in the tree of possible compile flags.
The style of "make this code work against every possible standard library" is broken and results in insane spaghetti code. Instead, the BSD team rewrote OpenSSL in terms of a modern, complete C standard library. Then instead of making their LibreSSL cryptography code have conditional flags in it, they wrote shims for the standard library so that it would work on platforms where there are missing functions.
This results in far cleaner code that can be reviewed and tested with much greater confidence.
I dug up a couple of presentations by the LibreSSL team 9 years ago. It's full of "Wat!?" moments, such as discovering the OpenSSL has its own implementation of malloc & free! Why? Because on one platform they nobody uses any longer, those functions were "slow"! So now they have a custom-developed poorly maintained heap full of security issues. Worse still, that custom heap does not benefit from the security features of modern allocators or analysis tools like valgrind.
What you consider "insanity" was functional and useful at one point and may still be useful in some projects. I see systems in the wild running DOS (rarer and rarer) because there is still functional hardware that does not have modern OS support.
The OpenSSL codebase is a legacy codebase, for sure. That said, it's a pretty consistent one (even with all the macros). I don't actively hunt for bugs, but I know the codebase enough that when one or two exploit came out in the past, I knew the relative area where things were impacted.
Also, writing one's own memory allocation library isn't that far fetched, especially if you want to encapsulate platform quirks at a specific layer. I don't think it made the transition to Mozilla owned Firefox, but Navigator (the predecessor) had it's own encapsulation of memory management because, in part, all the platforms and architectures it would compile for.
Do watch the BSD team's video presentation, they cover everything you've said.
I don't want to re-iterate too much of it, but the gist was: "If Microsoft won't support DOS or Win16, why should the two part-time volunteers support it!?"
The OpenSSL team clearly did not have the time or budget to both maintain that many platforms and maintain the security of supported platforms.
If "some projects" or "some vendors" want to support esoteric platforms they can fork LibreSSL and add support at their own expense instead of at the expense of the larger community using SSL libraries at-scale on modern platforms for production workloads worth trillions of dollars to the economy.
I 100% agree with the BSD team's points and their approach, and whatever contrary argument you make has to also explain away Heartbleed, which was at the time the worst security vulnerability in history.
It's like arguing that: "Sure, the Wuhan Lab of Coronaviruses may have had some biosecurity lapses, but just because the world's biggest pandemic originated form there doesn't automatically mean those practices were a problem!"
(Or if you disagree with the lab-leak hypothesis, substitute unsanitary animal handling practices at the Wuhan Markets.)
A legitimate question I have, why can’t these legacy machines running DOS just run a legacy version of OpenSSL? I understand there’s probably security concerns etc, but if security is such a big concern why would anyone still be running DOS? And why would anyone on DOS feel entitled to software updates in 2023? I just have a hard time wrapping my head around the need for to provide any consideration for ultra legacy code like this.
Well FreeDOS is not a legacy OS, it is actively maintained one. Besides, DOS is the simplestg hard RTOS, due to being single-task, zero protection, close to the metal system.
> A legitimate question I have, why can’t these legacy machines running DOS just run a legacy version of OpenSSL?
Compatibility. OpenSSL is at its core a networking protocol library, and legacy versions of OpenSSL will not understand the only versions of the protocols accepted by modern systems.
Not all of the things they cut out are nonsensical, though. They laughed at the ifdowhile loop, for example,
if (C) { do { /* THINGS */ } while (C); }
but on a puny compiler and/or CPU this seems like a fairly reasonable way to express that C is unlikely to be true, but if it happens to be we’re going to spend a while to turning it false. Whether such code belongs in a TLS implementation is a different question.
(Cutting out inline assembly for rotation operations is even more obviously dependent on the presence of a modern, heavyweight compiler, as only those have—or can afford—an explicit list of idiomatic AST templates they match against your code.)
Portable version exists and the Linux world should have replaced openssl by now, but for unknown reasons this is yet to happen.
I am hopeful someday one of the larger distributions such as Debian will have the courage to step forward.