Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Basically, through a combination of clever marketing and actual impact, Heartbleed hit the Open Source community HARD, and left most people in the Open Source Community asking two questions: 1. How did this happen? 2. How can we stop this from happening again?

LibreSSL and openSSLRampage is the OpenBSD response, and, it's absolutely in keeping with their character. I admire the "Fuck it, let's just fix this shit" attitude that goes along with it.

The Core Infrastructure Initiative is the Linux Foundation's response.

They're two valid ways of dealing with the problem. the LibreSSL way is more direct, targetted, and, in a way, satisfying, especially if you run OpenBSD, and can gain from these efforts relatively quickly.

The "Core Infrastructure Initiative" is looking at it from a more holistic perspective and saying: OK, OpenSSL was in trouble and nobody noticed, what other projects are in the same situation, and how can we prevent what happened to OpenSSL from happening to other projects.

Neither way is necessarily "The only right way", or even better than the other way. In fact, both approaches complement each other. OpenBSD fixes the actual current problem child, Linux Foundation is on the hunt for the next problem child



Indeed! I 100% agree.

I know you didn't say this, but I do think its important to dispel the notion that this is somehow a "response" to LibreSSL. As far as I can tell, it's not; the two initaitives started in parallel. The Linux Foundation started reaching out to companies to join them in supporting projects that are important and not necessarily visible -- starting with OpenSSL -- at the same time the LibreSSL project was starting.

When I asked Jim Zemlin (Linux Foundation executive director) about LibreSSL yesterday, he wasn't familiar enough with the project -- but was certainly open to the idea of all projects working together (or even having CII support something like LibreSSL if it had the type of adoption that would make it a core part of the open web).

Even if this project had been in place when Theo and the OpenBSD guys forked OpenSSL, I still think they would have forked it and started LibreSSL. After all, they have their own ideas about crypto and security and their own plans for how to run a project.

And even assuming LibreSSL can become a true drop-in replacement for all existing OpenSSL installations (which I truly doubt), that doesn't mean it will. Look at MySQL vs. MariaDB. Maria is finally gaining default status in important projects, but it's hardly replaced MySQL and realistically speaking, it probably won't.

So even if you want to argue that LibreSSL is going to do a better job with fixing OpenSSL's flaws (which may or may not be true), the reality is, OpenSSL is not going to go away.

Given that reality, doesn't it make sense to at least have the biggest stakeholders in the project offer it support so that the small dev team can stop with the contract work and work on making OpenSSL better?


OpenSSL needs a competitor to keep them honest, because clearly they've failed at their duty to push back on TLS WG features, failed at deprecating old code (Tandem multiplication, really?) and failed at writing secure code.


"Duty" is a bit too strong a word for this don't you think?


Not in this case. There's an implied duty when you represent your work as being suitable for critical uses such as securing the world's communications.


I thought GnuTLS would have been the alternative to OpenSSL but apparently it fell short.


For a while, GnuTLS was faster to support newer TLS standards. But again, same boat of not taking a leadership approach to engage TLS WG.

More implementations:

https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementati...


Was there a project management level reason to it, or was it just not the right combination of people? Anybody know more?


nss and nspr, to name one alternative.


My impression is that the CII is far more corporate, just from the quick-skim overview. That can be good, but can also up a whole can of competitive interest worms.


Both very good solutions although i prefer the Linux Foundations answer.

I'm amazed however that it took the Heartbleed incident to make big companies realize that hey we have been using these free and open source pieces of software everywhere maybe we should contribute back with some money or a few full time employees working on it.


I think pretty solid arguments can be made for the position that the Linux Foundation approach is the better route actually.


As also noted, pretty solid arguments can be made that the OpenBSD approach is the better approach. My point was that they're not mutually exclusive, and this is definitely a win-win scenario, as we have the potential to get 1. A rock-solid open source SSL library 2. Less surprises in the future.


> pretty solid arguments can be made that the OpenBSD approach is the better approach

Not really. OpenBSD is making a OpenSSL replacement for OpenBSD. They might make a portable version, but they might not. They have made it clear they are not putting the FIPS compliance stuff back in and there's a good chance a lot of those sponsors are interested in that.

Secondly, you don't get to choose where donations go in OpenBSD. You donate to OpenBSD and they distribute wherever. You don't get to say 'I need this money to go to improving the SSL library.' That can be kind of an issue for things like this.


FIPS is actively harmful to security by virtue of being an empty and ill-conceived certification. Removing FIPS from an otherwise best available option is to the benefit of the industry at large.

By comparison, glossy marketing of a security effort offers no security benefits, and plenty of room within which to hide bad ideas such as FIPS.


As others have said, the technical arguments against FIPS don't mean anything when a huge potential customer requires it.


And huge potential customers don't mean anything to a non-profit open source ecosystem that actually care about security.


When did Red Hat and Google become non-profits? Did I miss something?


RedHat and Google can afford to add FIPS to their own Libre SSL if they want to stop using OpenSSL.


Come on. We have every reason to believe that an OpenBSD library will be easily portable. That's their way. And FIPS was evil and had to go.


You think they can be made, but can you make them?

Money on its own can't code though. Money or no money, you need people who can and will start fixing shit.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: