OpenSSL, OpenSSH and NTP to receive support from Core Infrastructure Initiative
linuxfoundation.org
"Network Time Protocol, OpenSSH and OpenSSL first projects to receive support; Open Crypto Audit Project to conduct security audit of OpenSSL"
linuxfoundation.org
And "Theo's a dick" doesn't qualify as a valid reason to not fund real security development. For the work those guys have done improving the security infrastructure of every operating system (they lead, others followed), the entire team deserves to be well-off dicks. It's to me the ultimate highlight of OSS's funding problem. People make millions/billions of dollars off of this software, and nobody ever contributes any of that back to the shoulders they stood on to make that happen.
I don't think it makes sense to leave OpenSSL to wither while that happens, especially since it's an actively used product.
That being said I'm far, far more confident in the OpenBSD team than I am the OpenSSL one.
It sounds a bit like voting for a president because he's the guy you feel you'd most enjoy having a beer with: short-sighted.
It is naive and shortsighted to dismiss non-technical reasons. Often they can be as important as the technical reasons, or even more.
Yeah, but people who give money usually tend to see that as a valid reason.
https://en.wikipedia.org/wiki/Theo_de_Raadt#DARPA_funding_ca...
If you feel better convincing yourself that this is not the case, feel free. But it is still a fact, and I do contribute financially to a lot of other projects.
Unless OpenBSD decides to change, that is the way to fund OpenSSH. Currently you don't get to decide how your donations are spent by them, OpenSSH isn't it's own spinoff funded group.
One reason may be that donations to the OpenBSD Foundation are not tax-deductible in the US.
"OpenSSH was created by the OpenBSD team as an alternative to the original SSH software by Tatu Ylönen, which is now proprietary software. Although source code is available for the original SSH, various restrictions are imposed on its use and distribution. OpenSSH was created as a fork of Björn Grönvall's OSSH that itself was a fork of Tatu Ylönen's original free SSH 1.2.12 release, which was the last one having a license suitable for forking."
"Theo's a dick" has nothing to do with why funds are being applied to audit and not to "just have OpenBSD rewrite everything".
A rewrite has the benefit that it will lead to manageable code, instead of the current mess. Clean code has less places where subtle bug can hide, that does not change just because you are doing cryptography.
Anyway, they should send money to both. Both are important, and those companies make so much money using free software, they shouldn't be choosing the projects with that fine granularity. The problem is that they won't, and as much as kyledrake does not like the answer, it's because of Theo. Yes, it's a stupid decision, but it does not make it less real.
I am not in the least bit interested in the Theo vs. Whoever drama subtext. This whole subthread strikes me as similar to any other thread about a charitable donation, where people come out of the woodwork to cast aspersions that money wasn't given to some worthier cause.
It seems appropriate to point out that auditing and fixing the details is just patching symptoms -- and that many think a longer-term solution is needed.
The reasons to fund the audit, and two full time devs, are clear.
1. Removing a ton of broken, obsolete, or poorly-designed code 2. Fixing bugs and incorporating fixes from the official OpenSSL bug tracker
In short, the 'good parts' of LibreSSL are a team of people willing to devote significant time and effort to making the OpenSSL codebase secure, clean, portable, and trustworthy. That's something that the OpenSSL devs either didn't have the time or energy to do.
As for interoperability: OpenBSD's process has always been to write a single core with a single target (OpenBSD) and then to have a separate team take care of platform-specific issues. This allows the team doing security work on LibreSSL/OpenSSH to focus on the results by writing a single implementation, and the porting team can spend their time porting that implementation to other platforms (rather than having someone implement functionality while trying to be aware of how each platform handles things).
It's worked well for OpenSSH so far, so I don't see a problem with using the same pattern for LibreSSL.
Personally I've never donated for auditing, but in my free time I do look at code myself.
Today I had to install a proxy server, so I downloaded the source to Apache's traffic server. Within five minutes I'd decided that the code contained enough problems that I couldn't recommend using it.
Now I've reported those bugs, and made a contribution..
You say that, but it's not as though this is a fundamentally hard problem. How many servers are running nginx today vs. even a few years ago?
Moreover, the biggest problem sits with the biggest, and often most capable, internet companies. So having a reasonable path for them to a more secure TLS implementation, even if it meant hand rolling their own packages or building from source, is potentially a big win for the internet in general.
And, of course, eventually switching from openssl to libressl will become as easy as spending a couple minutes with a package manager.
The fact is that this industry has a track record of keeping up to date technologically. This isn't some corporate IT in the industry gulag saddled with bullshit LoB apps that depend on IE6 in perpetuity. We're talking about the most capable and savvy tech companies in the world. If there's a better option to be had, it'll see high adoption rates.
How many years did it take to get there? How many servers are still running apache?
> And, of course, eventually switching from openssl to libressl will become as easy as spending a couple minutes with a package manager.
Eventually, maybe. That's no reason not to audit openssl right now, that people cannot switch - especially the ones that use platforms that the OpenBSD team decided to remove support for.
As for auditing OpenSSL, the OpenBSD team has found so many problems, misdesigns, misfeatures, idiotic decisions, and bugs, that it seems a shame to repeat that work again. If I had to choose, I'd say give the OpenSSL name to the OpenBSD guys, let them take over the project officially, and let the folks behind the OpenSSL foundation handle things like platform-dependent code, FIPS compliance patches, etc.
And there is no question about it they absolutely will introduce new bugs. But hopefully the increased scrutiny and easier to read code means that they are less likely to have extremely bad bugs latent in the codebase for years without anyone noticing, as has been the case with OpenSSL.
The reason I don't donate to them is that I feel like most of my donation will be going towards something I don't care about.
Consider that ntp.org is being funded, not OpenBSD (and their inferior OpenNTP).
NTP is infrastructure. OpenBSD is not.
Consider that OpenSSL is being funded, not OpenBSD ( and their unusable at this point libressl project).
OpenSSL is infrastructure.
OpenSSH got some funding, because it is widely used. It is infrastructure, not 3-5 people scratching an itch in a project.
> OpenSSH got some funding, because it is widely used. It is infrastructure, not 3-5 people scratching an itch in a project.
I'm not sure what to say as I think you missed my point by a mile. Giving money to OpenSSH or LibreSSL is giving money to OpenBSD, it is the same people and same foundation.
OpenSSH and, now, LibreSSL are project written to OpenBSD first and then ported. Ported platforms that don't have the libraries these projects expect (which are developed for OpenBSD) have those functions ported[1]. They are the same project with parts ported to other platforms.
I have no clue what the 3-5 people comment is even about.
1) with some exceptions such as generation of entropy since only the OS can do that well.
Given their work is avowdly OpenBSD-only and portability has to be added on in the case of e.g. OpenSSH it would seem a dead-end for anyone who wants broader platform support.
I'm not sure why you brought up OpenSSH, since it's by far the most widely used SSh implementation in the world...
Linux Foundation wants things which run on Linux. Trying to figure out how you fund the BSD version + porting effort leads to a weird incentive scheme.
What i can't really comment on myself, but am reading from the OpenBSD guys is, that the OpenSSL team does quite well with FIPS consulting and has no increased interest in improving the library.[0]
Even if those claims are not true, it would be nice to see several other TLS libraries (GnuTLS, LibreSSL etc.) getting sponsored to get some healthy competition. Maybe, they could even directly compete for shares of the funding by the Linux Foundation in some way.
[0]: http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.htm...
> Also, the income they earn though their paid consulting work supports their unpaid work on OpenSSL, so by hiring OpenSSL team members you are not only solving your own problems but also helping to ensure the long term viability of the OpenSSL product.
They also on their website list hourly consulting starting at $250/hour. Neither of these describe how much they get out of this, but it seems reasonable to say that the "OpenSSL runs of $2k/year" line is disingenuous at best.
Is it? The last contract listed on that page is 4 years old. Maybe they don't regularly get contracts.
It seems that own of the only ways of dealing with the OpenSSL code is to strip out the code for a large number of, should we say "less used platforms". Is the OpenSSL developers willing to drop support for 16 bit Windows or OpenVMS?
They either need to properly maintain it or drop it, and they don't have enough money to maintain it.
There are recent builds of OpenSSL for OpenVMS:
http://polarhome.com/openssl/ http://www.openvms.org/stories.php?story=14/04/11/6422157
HP's version is a bit older:
http://h71000.www7.hp.com/openvms/products/ssl/ssl.html
Free OpenVMS accounts:
Is there anything except resources that prevent you from moving to a more modern platform? Of course, "it works" is a valid argument there, too. But you seem to be writing new code, too.
OpenVMS has some really good ideas baked into the OS that we've had to reimplement or find off-the-shelf solutions for our new platform (for example a distributed key-value store (called "logicals"), a job queue system, and a clustered filesystem) but nothing so earth-shattering that it would keep us on VMS.
The biggest downsides are expensive hardware (OpenVMS is designed around clusters of a few beefy boxes, rather than many commodity boxes), lack of community knowledge, and lack of new software available for the platform. (End of life is also looming: http://h71000.www7.hp.com/openvms/openvms_supportchart.html .)
-/* Added for T3E, address-of fails on bit field (beckman@acl.lanl.gov) */
-#ifndef BIT_FIELD_LIMITS
memcpy(&server.sin_addr.s_addr, ip, 4);
-#else
- memcpy(&server.sin_addr, ip, 4);
-#endif
When you support the OpenBSD Foundation you support:
- OpenBSD - OpenSSH - OpenBGPD - OpenNTPD - OpenSMTPD - LibreSSL
The wording makes me think that the initiative will be supporting something other than OpenNTPD
1: http://arstechnica.com/information-technology/2014/04/tech-g....
As a result, the people behind the OpenSSL Foundation are NOT taking a cut of the monies from the CII.
(edit: expanded on what is most important)
IMHO, libressl is a mistake. It's splitting resources over something that needs to be as air-tight as possible. I'd much rather have 1 really really good ssl library that everyone uses instead of 2 so-so ones.
OpenSSH and LibreSSL are both a part of OpenBSD. So when you donate to the OpenBSD Foundation, you are very much donating to one project.
> one that feels a fork was more appropriate than just fixing the problems in openssl
You can't start fixing things in other peoples' source tree just like that. I'm pretty sure nothing useful would've come out of it if the OpenBSD folk had sent half a million lines in diffs to OpenSSL; http://www.openbsd.org/papers/bsdcan14-libressl/mgp00026.htm...
Yes, you can. It's called contributing to a project. If the "half million lines of diffs" were actually things needing fixing, then the upstream team would accept them. If they are not necessary changes (such as ripping out all windows compatibility), then no, they would reject such changes.
It will take years, maybe a decade before a new ssl library becomes the "default". OpenSSL has a lot of ground covered and a lot of history. Yes, it's common knowledge that libressl started before heartbleed, but the reasons for the project being started are mostly along the lines of:
1) We don't think upstream would take these changes
2) We don't like some aspects of the design philosophy
3) We can do it better.
All 3 reasons can be collapsed into a more focused effort to fix the already existing and very good ssl library; openssl.
I take it you've never dealt with an inactive/apathetic upstream before? Just because someone is the steward of a project does not mean they should be. This is perhaps one of the most valid reasons to fork!
The LibreSSL team says that there were big problems on the tracker that languished for years, such as OpenSSL not working correctly when you disable their custom memory allocator. If the OpenSSL team can't deal with bug reports in a timely fashion, what makes you think they will bother reviewing and merging hundreds of thousands of lines of code?
Bugs being in a tracker for years is not uncommon.
Here's OpenSSH's tracker:
https://bugzilla.mindrot.org/buglist.cgi?bug_status=__open__...
331 bugs, a large majority of which are pre 2012.
This is not a sign of inactive/apathetic developers. It's a sign of big and old projects.
I have no doubt the OpenBSD folk are excited about this now... but 5 years from now? More? What's the long term viability of this project? Will they eventually put all OS's on an equal footing instead of *BSD's first and port to other OS's?
Forking was not the answer. The answer was to fix the perceived problems in OpenSSL and make it as solid as it can be. It's splitting talent and resources unnecessarily. Especially when the two projects are under the same umbrella (OpenBSD Foundation).
But that is what the fork is, OpenSSL with new stewards. What is your objection? That they are using a different name? That they decided to remove certain platforms which were a maintenance burden? That FIPS is broken by design and therefore isn't a priority? I imagine the OpenSSL team disagrees with the LibreSSL team on all of these issues. The only option was a fork.
> Right now, native libressl only works on bsd's, when openssl codebase works on many os's. There are ports being made, which will introduce more bugs.
One step backwards, two steps forward.
Why? The LibreSSL team are keeping the API backwards compatible, so it will literally be a drop-in replacement (once there are ports to other platforms). It should just require a recompile.
Since the barrier to entry will be fairly low, it is foreseeable that it could become popular quite quickly.
That's reasonable, but those aren't the options at play here. Not only because GnuTLS is already a thing, but the chances of OpenSSL becoming really really good are questionable.
An OpenBSD guy gave a talk a few weeks back where he said that Heartbleed wasn't the reason for the split, it was the reason for digging into the code and realizing that OpenSSL under current leadership isn't capable of being a really really good option.
That's what libressl is about. If you're in any doubt, please see this talk: https://www.youtube.com/watch?v=GnBbhXBDmwU
The doubt is whether or not it is a good call to fork openssl instead of attempting to get changes into upstream that fix it and make it better, safer, more reliable.
https://bugzilla.mindrot.org/buglist.cgi?bug_status=__open__...
Fork it now!
~~~
Seriously, stop buying into all the hype generated by heartbleed. Things will simmer down, and it's doubtful libressl will replace openssl anytime in the next 5 years as the standard default ssl lib for many things.
I do not buy into OpenSSL devs not wanting bugfixes.
Where are the public rejections/closures of submitted fixes? There aren't any. There are just assumptions that they wont take certain patches, or submitted patches waiting for review (how about you jump in and help review?).
http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.htm...
Though, bind 10 hasn't gone as well as planned - that's been other issues than funding though - https://ripe68.ripe.net/presentations/208-The_Decline_and_Fa...
https://duckduckgo.com/?kh=1&q=Huawei&sites=www.schneier.com...
Presumably, the NSA hacking is a reason for Huawei to start caring a great deal more about investing in security.