I haven't really stayed up to date, but I recall the primary issue with openssl at the time of heartbleed was that it was basically a poorly manned project with little funding, yet billions of people rely on it daily. Has that situation changed at all since? It's ironic the OP laments them "not learning lessons" since heartbleed, but if there was any lesson to learn it is that if everyone is going to rely on a piece of software it should get some love from the broader community. It's good he found it but his harsh scolding tone is unfair given the situation...unless openssl has multiple SV salaried employees working full-time on it by now.
Well, he shows the bug can be found after a second when fuzzing!
Some years ago, I have reproduced Hanno Böcks fuzzing to find Heartbleed "again". It wasn't that hard to do and I was completely new to the whole thing. Everybody had time to get up to speed with that as I did and implement it in the workflow.
The manpower problem becomes worse over time when you do poor quality work, because things are not really done and you cannot fully concentrate on further work because there is so much maintenance and rework. Stellar work doesn't have to cost much. Good, reliable software can get built extremely cheaply.
Of course, OpenSSL and many other projects face many typical problems. Protocols are under specified, sometimes extremely complicated or the way the protocol is described is extremely unreadable and for all these reasons the specifications are not crystal clear. Then you have practical implementations that can vary a lot, if the standard is poorly written/ thought out or one implementing party has a monopoly and can do whatever they want they tend to diverge. Then of course, there are protocols which originally were simple but got extended over time with things that are used everywhere but not really standard and such. Also, you can have wrong tools or use your tools badly. C and many other languages require a lot more discipline than some viable alternatives that would in many cases cream at you or handle the situation for you. C is like a table saw without safety. Yes, it does get the job done but you might loose a finger or a hand in the process and even the best do at some point.
Parsing anything in C seems to me to be a clear "danger" zone, where you tripple check everything.
I've contributed to OpenSSL in the past, but not regularly.
Heartbleed was partially because they hadn't fully adopted techniques like fuzzing in regular use, so when researchers started fuzzing everything, out popped heartbleed. Now OpenSSL does fuzzing on (every PR, IIRC?) The author is a bit unfair in calling the project out as if they don't do it.
There still aren't a lot of developers on it relative to the complexity of the project though. Frankly there are large parts of the codebase that are pretty intimidating to touch, like the X.509 stuff implicated here.
> There still aren't a lot of developers on it relative to the complexity of the project though. Frankly there are large parts of the codebase that are pretty intimidating to touch, like the X.509 stuff implicated here.
Sounds like the old problem of "Well, the hospital might have enough surgeons overall...but this case is gonna need a real good pediatric brain surgeon or two, and that's a different story..."
Google approached this issue by simply creating and maintaining their own fork of OpenSSL, called BoringSSL. Has it been affected by this most recent issue?
Has BoringSSL been widely adopted? The OpenBSD people forked to LibreSSL which looked very promising (coming from people who make their main obsession about security) but seemed to quickly burn out at least on Linux hosts
It was never meant to be, it's only providing a subset of the features openssl has.
>The OpenBSD people forked to LibreSSL which looked very promising (coming from people who make their main obsession about security) but seemed to quickly burn out at least on Linux hosts
In the beginning yes it was, they moved fast on cleaning up OpenSSL codebase. The problems began because it's not explicitly a goal to maintain OpenSSL compatibility, so distros had a huge maintenance burden patching things to work with it. Eventually the distros that were maintaining it (Void and Gentoo?) got tired of it and decided OpenSSL had gotten through the worst of its problems.
Then OpenSSL 3 dropped, once again making it annoying to patch for and introducing issues like this CVE. I think Alpine was discussing looking at LibreSSL again but I think that ship has sailed.
I'm pretty sure even OpenBSD packages OpenSSL in ports for third party software, since so many pieces of software basically require it and do not work with LibreSSL anymore.
I suppose a Linux distro could hypothetically take the same approach and use a mixture of both, but realistically most people don't want to bother with that.
Personally I'd love a Linux distro with a BSD-style base system and extra packages kept separately, but the closest to that would be ... Slackware with pkgsrc or something I guess.
> I'm pretty sure even OpenBSD packages OpenSSL in ports for third party software, since so many pieces of software basically require it and do not work with LibreSSL anymore.
Theo Buehler talked about the current status of LibreSSL compatibility at EuroBSDcon last week. To take some quotes:
“> 2000 OpenBSD ports link against libcrypto or libssl” [i.e., LibreSSL]
