| As the LibreSSL devs have said, heartbleed was not the cause of the fork. They forked the project because they believed the OpenSSL project repeatedly made bad decisions. From https://www.openbsd.org/papers/eurobsdcon2014-libressl.html > Heartbleed can't even be considered the worst OpenSSL vuln. Previous bugs have resulted in remote code execution. Anybody remember the Slapper worm? That worm exploited an OpenSSL bug (which was apparently titled the SSLv2 client master key buffer overflow) which revealed not only encrypted data or your private key, but also gave up a remote shell on the server, and then it propogated itself. Yeah, I'd say that's worse. But no headlines. > I mention this just to reinforce that LibreSSL is not the result of "the worst bug ever". I may call you dirty names, but I'm not going to fork your project on the basis of a missing bounds check. > why fork > Instead, libressl is here because of a tragic comedy of other errors. Let's start with the obvious. Why were heartbeats, a feature only useful for the DTLS protocol over UDP, built into the TLS protocol that runs over TCP? And why was this entirely useless feature enabled by default? Then there's some nonsense with the buffer allocator and freelists and exploit mitigation countermeasures, and we keep on digging and we keep on not liking what we're seeing. Bob's talk has all the gory details. You can see "Bob's talk" here: https://www.openbsd.org/papers/bsdcan14-libressl/ though I think there is a YouTube video somewhere. Also I would like to point out that Google also forked OpenSSL. So it seems that the LibreSSL folks are not the only ones who thought a fork was necessary. |
A lot of that uglyness seems to come from the fact that OpenSSL wants to support all environments (even DOS). I wonder why distributions haven't switched since LibreSSL was made to be API/ABI compatible with openSSL and target a POSIX OS. This would be much more justified than the ffmepg / libav thing imo.