11–20 of 65 posts
I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnerability from an established project and immediately jumping ship to a brand new one with less eyes and reputation seemed hasty to me.
That doesn't sound like an accurate description of LibreSSL, what with it being a part of OpenBSD.
I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnerability from an established project and immediately jumping ship to a brand new one with less eyes and reputation seemed hasty to me.
> jumping ship to a brand new one with less eyes and reputation That doesn't sound like an accurate description of LibreSSL, what with it being a part of OpenBSD.
I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnerability from an established project and immediately jumping ship to a brand new one with less eyes and reputation seemed hasty to me.
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.
Earlier quoted context omitted.
> jumping ship to a brand new one with less eyes and reputation That doesn't sound like an accurate description of LibreSSL, what with it being a part of OpenBSD.
This is a fair point, but it is being used as standard on other operating systems. I remember people switching to Void Linux en masse after they made it their standard mostly as a result of Heartbleed.
...so even more people are looking at it? not sure what problem you think is happening here.
I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnerability from an established project and immediately jumping ship to a brand new one with less eyes and reputation seemed hasty to me.
Example: "“Do you really want to build OpenSSL for 16-bit Windows? Well, we don’t.”"
https://opensslrampage.org/post/83952304402/do-you-really-wa...
I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnerability from an established project and immediately jumping ship to a brand new one with less eyes and reputation seemed hasty to me.
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 bu…
"LibreSSL with Bob Beck" at https://www.youtube.com/watch?v=GnBbhXBDmwU
This was the engineer who helped set up the new policy: https://awe.com
To be honest, maybe it's a good idea. It depends on how much support Huawei is willing to give OpenSSL.
This made me think of BoringSSL and LibreSSL again. Looking up on Wikipedia it seems that LibreSSL is focused on OpenBSD and removed lots of legacy code. BoringSSL (Google) got renamed to Tink but I couldn't not find much more. It's sad to see that duplication of effort but it's also the force of open source
I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnerability from an established project and immediately jumping ship to a brand new one with less eyes and reputation seemed hasty to me.
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 bu…
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.