6 ms·

> profoundly better How? Better/newer algorithms? Faster? Cleaner code? Better APIs?

jiggawatts 3y ago
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. Watch: https://www.youtube.com/watch?v=-4psTQ1sX7s https://www.youtube.com/watch?v=-4psTQ1sX7s I love the bullet point list of insanity they cut out: - Ebcdidc support - DOS support - MacOS Classic support (pre OS 10) - Win16 support - VM Support - Big-endian AMD64 support (!?) That last one is a story in and of itself...
- TillE 3y ago
  > - Win16 support It also doesn't work on Windows XP. OpenSSL does. This is, unfortunately, still important for many users.
- sillywalk 3y ago
  They called it OpenSSL Valhalla Rampage, and the comments are hilarious. https://opensslrampage.org/ https://opensslrampage.org/
  - mananaysiempre 3y ago
    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.)
    - jiggawatts 3y ago
      Security code must be correct above all else. Too-clever tricks for tiny performance gains that interfere with readability are the polar opposite of what an SSL library ought to be doing. Such libraries ought to never trust compilers because compilers are ever changing, untrusted things. The right approach is clear readable high level code interspersed with inline assembly for critical sections such as constant-time operations. Speaking of which: OpenSSL did that wrong too. They merged some AES NI optimisations without having the CPUs to test it on. This lead to the one and only crash I’ve ever experienced due to a CPU upgrade! Stop justifying what is clearly a trash fire.
- jmspring 3y ago
  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.
  - appplication 3y ago
    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.
    - SomeRndName11 3y ago
      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.
      - patmorgan23 3y ago
        So bump a major version and only do security fixes for the old one.
    - cesarb 3y ago
      > 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.
- ciupicri 3y ago
  What DOS and Win16 support? OpenSSL 3.x requires Windows 10 as far as I know. Even Windows 7 is not supported anymore.

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. Watch: https://www.youtube.com/watch?v=-4psTQ1sX7s https://www.youtube.com/watch?v=-4psTQ1sX7s I love the bullet point list of insanity they cut out: - Ebcdidc support - DOS support - MacOS Classic support (pre OS 10) - Win16 support - VM Support - Big-endian AMD64 support (!?) That last one is a story in and of itself...

TillE 3y ago
> - Win16 support It also doesn't work on Windows XP. OpenSSL does. This is, unfortunately, still important for many users.
sillywalk 3y ago
They called it OpenSSL Valhalla Rampage, and the comments are hilarious. https://opensslrampage.org/ https://opensslrampage.org/
- mananaysiempre 3y ago
  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.)
  - jiggawatts 3y ago
    Security code must be correct above all else. Too-clever tricks for tiny performance gains that interfere with readability are the polar opposite of what an SSL library ought to be doing. Such libraries ought to never trust compilers because compilers are ever changing, untrusted things. The right approach is clear readable high level code interspersed with inline assembly for critical sections such as constant-time operations. Speaking of which: OpenSSL did that wrong too. They merged some AES NI optimisations without having the CPUs to test it on. This lead to the one and only crash I’ve ever experienced due to a CPU upgrade! Stop justifying what is clearly a trash fire.
jmspring 3y ago
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.
- appplication 3y ago
  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.
  - SomeRndName11 3y ago
    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.
    - patmorgan23 3y ago
      So bump a major version and only do security fixes for the old one.
  - cesarb 3y ago
    > 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.
ciupicri 3y ago
What DOS and Win16 support? OpenSSL 3.x requires Windows 10 as far as I know. Even Windows 7 is not supported anymore.