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.
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...