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
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?
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.
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.
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.
Money on its own can't code though. Money or no money, you need people who can and will start fixing shit.
My one real question: How well has the Linux Foundation managed its money in the past? Are they going to be an effective steward of this fund?
The Linux Foundation handles the Linux kernel, so they have a good track record in that regard. They also have worked on some less-successful (but very well-managed) initiatives like Meego and now Tizen.
The members are big corporations and as a result, the auditing process and outlay of funds isn't something I'd be concerned with.
The greater (potential) concern would be over how the corporate sponsors could influence a project. Zemlin assured me that the SOP is not to interfere with existing operational structures or governances of a project -- so they wouldn't have any impact on how the OSF is run, for instance -- and certainly, in the case of the Linux kernel, corporate sponsorship hasn't dictated Linus's direction of the project.
That said, I think the level of influence a corporation could have over a project is probably directly related to how a project is initially structured. Tizen, as an example, is in partnership with the Linux Foundation, but is largely led by Samsung and Intel. That's totally fine, and was that way by design.
I would be concerned about projects that might not have strong leaders (like Linus). Of course, one could argue that if that's the case, the project might have bigger problems than being co-opted by other entities.
Let's be very clear on this subject, though: Microsoft was doing it for their own benefit. It wasn't altruism.
A pragmatic Microsoft might be edging away from a "Windows or Death!" attitude. Didn't we read that after they bought Skype they replaced its skeezy "volunteer" supernodes with 10,000 systems running Linux? E.g. https://www.google.com/search?q=microsoft+skype+linux+supern...
They also ship software like OpenSSL, but they actively discourage its use in Mac software in favour of SecureTransport.
Don't get me wrong, they should give back (and they do), but it's kind of surprising how much of the standard Linux stack they don't actually ship.
They also have a lot of contributions to LLVM/Clang, as well as several other open-source projects.
It's very well established that Apple is allergic to the GPL, and is willing to pay good money to avoid dealing with it whenever possible.
Mozilla Foundation once donated 10K USD to OpenSSH after OpenSSH's call for donation. Not many others did.
OpenBSD responds by rolling up sleeves and fixing the problem.
Or maybe it's not so mysterious, the principle companies involved have a long record of benefiting from OpenSSH and never contributing to that either.
The vast majority of people who use OpenSSL don't need FIPS compliance, and LibreSSL will provide them with a more solid, better reviewed, more secure, lightweight, reliable drop-in replacement. It's hard to argue with that.
If none of the major vendors will ship a non-FIPS certified crypto lib, then where exactly will it get used?
Once the code is audited and bugs corrected portability is next. This will only happen if the right team is in place, the community wants it, and sufficient funding is secured.
However, I don't think this is a bad thing. To do a massive clean up, you must be able to focus on code that you can actually compile and test. Dead code, code behind ifdefs is likely to rot. If it wasn't very rotten already.
It is better to do a fresh port of a cleaned up code base for modern systems.
How many years have you been benefiting from the work that was put behind OpenSSL ? What about being a bit grateful for the amazing work they did with basically no funding ?
Windows used to use BSD stuff for the network stack. OSX uses a lot of BSD stuff. These are not poor companies. Including a per-licence donation of a few US cents would have been a significant contribution.
Since they also develop OpenSSH, wouldn't that qualify them to also work on the algorithm parts?
But, TLS is a huge spec, and I think the OpenSSL guys are going to have more experience in things like "Older (and widely deployed) F5 networking devices attempt to parse a TLS Handshake as SSLv2 first, which means that due to the overlapping structure, an SSLv3/TLS client-hello of length 256 - 511 bytes, it can't tell if a certain byte is a "message type" of 1 (SSLv3/TLS) or it is the "length high bits" to be 1 (SSLv2). Therefore, despite no mention in the spec, it's useful to pad out the CLIENT_HELLO to remove the ambiguity." (Just to use a recent example)
TLS is a horrible mess of a spec, and the real-world implementations are even grittier. While I'm not knocking the OpenBSD guys at all (and I think what they're doing is great), let's not forget that OpenSSL got it's place because despite the code quality, it's one of the most fully-featured TLS stacks out there due to the knowledge and experience of it's developers. I hope to see lots of code flowing in both directions between the two projects.
So far, I'm thinking that the odds that I'd introduce some horrible bug (either along the lines of the Debian ssl keygen bug) or perhaps more likely increase vulnerability to timing attacks outweighs the potential benefits (a tighter, more transparent code base, with fewer features and hopefully fewer bugs).
However, I will personally refrain from funneling money into any project if it is not clear that money will make a difference. It's like donating to charities who cannot ensure the money actually ends up in the right place and actually helps the lives of the people who they (cl)aim to help. I'm more likely to donate to projects that have proven their worth, like OpenBSD. The proof, hard work, should come first. Donations might follow.
Part of the problem with funding open source is that an agent acting only in their own short term interests is going to say: "ok, someone already did the hard work, the results are free!", and won't donate anything.
What other people do (or don't do) doesn't really matter. If I refuse to donate to a project, and Apple makes a non-free derivative of that project, that project is still free and you can still fund it.
I agree with your assessment of who to donate to, by the way, I'm just saying that the whole thing is a bit difficult.
This is a distinction without difference. If you're not getting money for doing open source development, your open source development has no funding.
Think OpenSSH -> OpenSSH-portable.
What if it also had fewer bugs, is more receptive to contributed bug fixes, runs clean in Valgrind, etc.?
OpenBSD is already reaping the benefits from a better TSL implementation in -current so it's a win for our project as well.
This is a win win scenario.
> By raising funds at a neutral organization like The Linux Foundation, the industry can effectively give projects the support they need while ensuring that open source projects retain their independence and community-based dynamism.
I somehow can't imagine an organization named "Linux Foundation" to give money to OpenBSD and other non-Linux related open source projects.
Why not ? I could imagine them giving money to OpenSSH developers at least, seeing how it is part of the core infrastructure.
Also, would you have imagined Microsoft giving money to an organization named "Linux Foundation" ?