It looks mostly like they've taken on-board the criticisms from the OpenBSD developers and have decided to get their house in order.
It will be interesting to see whether this turns out to be just words or if they'll stick it through. If the actually implement what they're planning the future for OpenSSL will be a lot better.
Eh, it shouldn't be that bad. The Google and OpenBSD teams certainly can operate only independently and they have both pledged to cooperate with The OpenSSL Project (as well as with each-other).
This is great news indeed. At least now we know the OpenSSL developers recognize the problems they have and that they are actively working on fixing them.
While I would not necessarily prioritize this above any of their other concerns mentioned in the roadmap, I would love to see openssl use a more standard build process instead of generating code through perl as part of their build
It would also be nice if they tested builds with infrequently used options. I've tried building with documented options, e.g. no-comp (disables compression) and it completely failed. Presumably because the CPP generated something that no longer built using that option.
Yes. It's also funny that if you look at each of the 8 points identified in the posted link, they're like all have already been identified and many have already been fixed in LibReSSL.
Why use OpenSSL, if LibReSSL already has had a head start on each issue? And OpenSSL probably doesn't even intend to address some of these, like removal of FIPS support.
Can they remove FIPS at all? Big distributions will certainly want to (have to) offer the FIPS-capable version to some of their customers. I imagine it would cause some serious overtime at RedHat for a number of weeks (months?) if OpenSSL decided to drop FIPS completely.
If RedHat or Oracle needs FIPS, they should be the ones who are supporting it, not the rest of the unpaid open-source volunteers.
I'm pretty sure that OpenBSD, Debian, Slackware, Arch Linux and many others don't care about supporting some insecure and obscure government standards.
In fact, FIPS was removed from LibReSSL in OpenBSD due to being unmaintained and insecure.
> I don't expect much to come from rewarding failure.
What about adequately supporting developers who have provided a product used by a huge number of people? Yes, they've had failures and have clearly done some things wrong. But they have also made positive contributions. I guess it's a matter of whether one thinks the baby should be thrown out with the bathwater.
Not necessarily. They could start by rolling in the changes from LibReSSL. This is exactly what happened to GCC back in the day. GCC development stalled, EGCS forked it, and eventually FSF declared EGCS as the official GCC thereby re-uniting the two projects.
Wouldn't be entirely surprising to see something similar happen here.
There are different degrees of failure. Expecting someone to work for free for you(you as in all the big and small companies making a ton of money) while not inspecting the code for bugs is one of them. Blaming the resource constrained developers accomplishes nothing.
I think that just points to failure on both parts. Users of OpenSSL failed to correctly vet the codebase, and OpenSSL developers (according to numerous reports I've seen) failed to build a secure and clean (in this case, I think those are related) codebase.
This happens occasionally, a product is the leader in it's market because it was the only game in town, but eventually it's replaced as something beats it in one or more of the categories of features, speed, reliability, or freedom. See ssh.com vs OpenSSH.
The truth of the matter is, many people have concerns about the security of OpenSSL (and IMHO, rightly so), and no matter how bad we feel for the developers, this is not a case where we should trust in our loyalty. This is our personal security, the security of the businesses we work for, and the customers that use them. I can't in good faith use anything but what I consider the best choice, given whatever constraints I already face.
I never asked any OpenSSL guys to work for free for me. Btw. I am contributing to FOSS projects before you are accusing me that I never done anything to the community. I totally understand the responsibilities of open source developers. Having software that supposed to provide security is a huge responsibility and in those projects following best practices (not re-implementing malloc badly, etc.) is insanely important. Just because it is free it does not mean that you can throw out everything we know about software engineering, and it does not justify broken software. There is a tendency in the software community that if it is free it can be crap and nobody can complain about it. This is bad attitude. If you can't write great software just please don't do it and try to hide behind the open source flag.
You're vastly overstating the difficulty in porting LibreSSL. It's 99% POSIX standard use of APIs and modern portable C except for a few security related functions they use that are non-standard such as explicit_bzero, reallocarray, and strlcpy.
It's also a couple of months old. Give it a year's time (or half that, even) and that possibility of a proper non-OpenBSD *nix port will be that much more likely.
I expect Debian and its derivatives to offer LibreSSL eventually. There is interest and no good reason not to.
However, I expect Fedora and its derivatives to stick with openssl-fips. Red Hat makes a big deal of FIPS due to selling to customers who are subject to the FIPS bureaucracy. :-(
I don't understand why a code review system has to take 3 to 6 months. That seems backwards to me: it should be the first step to improving the project. Every one of the changes listed in the roadmap should be reviewed and signed off by at least one other peer in the project.
They need to recruit more people to make it possible i guess?
I don't know I agree with you. Its absurd to have a project of this scale without code review.
Sounds good to me. If followed through, OpenSSL and libressl portable could possibly converge on practically identical code bases.
It is a little weird though that it's almost the libressl game plan, verbatim. It could literally just say "do whatever libressl" does.
Some of the specifics, like memory management is dangerous, fips code is tangly, win16 support is obsolete, seem a little too familiar. We haven't really tried to make an exhaustive list of issues to fix in libressl. I know there are things we haven't looked at yet. But for the OpenSSL roadmap to match 100% our public work is weird. They haven't found anything to fix that we've overlooked?
Also, there are definitely some problems in OpenSSL that we've identified, but haven't talked about. I'd expect any independent review/roadmap planning to identify them. They're missing from this list.
30 comments
[ 5.6 ms ] story [ 64.2 ms ] threadIt will be interesting to see whether this turns out to be just words or if they'll stick it through. If the actually implement what they're planning the future for OpenSSL will be a lot better.
Things are looking up, IMO.
This definitely increases my confidence in them.
24-Jun-2014: Team status changes including six new development team members
The article listed links to: https://www.openssl.org/about/
Hopefully the new team can deliver on the promise in this roadmap.
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
I'll be running LibReSSL, and I expect most Linux distributions to do the same by default once the Linux port is released.
Why use OpenSSL, if LibReSSL already has had a head start on each issue? And OpenSSL probably doesn't even intend to address some of these, like removal of FIPS support.
I'm pretty sure that OpenBSD, Debian, Slackware, Arch Linux and many others don't care about supporting some insecure and obscure government standards.
In fact, FIPS was removed from LibReSSL in OpenBSD due to being unmaintained and insecure.
What about adequately supporting developers who have provided a product used by a huge number of people? Yes, they've had failures and have clearly done some things wrong. But they have also made positive contributions. I guess it's a matter of whether one thinks the baby should be thrown out with the bathwater.
Wouldn't be entirely surprising to see something similar happen here.
This happens occasionally, a product is the leader in it's market because it was the only game in town, but eventually it's replaced as something beats it in one or more of the categories of features, speed, reliability, or freedom. See ssh.com vs OpenSSH.
The truth of the matter is, many people have concerns about the security of OpenSSL (and IMHO, rightly so), and no matter how bad we feel for the developers, this is not a case where we should trust in our loyalty. This is our personal security, the security of the businesses we work for, and the customers that use them. I can't in good faith use anything but what I consider the best choice, given whatever constraints I already face.
English is hard man, I know.
Which is not wrong, but I wouldn't say it's right now well-baked for inclusion in major Linux distributions.
However, I expect Fedora and its derivatives to stick with openssl-fips. Red Hat makes a big deal of FIPS due to selling to customers who are subject to the FIPS bureaucracy. :-(
It is a little weird though that it's almost the libressl game plan, verbatim. It could literally just say "do whatever libressl" does.
Some of the specifics, like memory management is dangerous, fips code is tangly, win16 support is obsolete, seem a little too familiar. We haven't really tried to make an exhaustive list of issues to fix in libressl. I know there are things we haven't looked at yet. But for the OpenSSL roadmap to match 100% our public work is weird. They haven't found anything to fix that we've overlooked?
Also, there are definitely some problems in OpenSSL that we've identified, but haven't talked about. I'd expect any independent review/roadmap planning to identify them. They're missing from this list.