5 ms·

OpenSSL Project Roadmap

70 points by dankohn1 12y ago

nodata 12y ago
So now we have a third refactor?
- Twirrim 12y ago
  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.
- ihsw 12y ago
  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). Things are looking up, IMO.
- Strilanc 12y ago
  This problem is important enough to justify multiple attempts in parallel, despite the redundant work.
ayrx 12y ago
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. This definitely increases my confidence in them.
josephlord 12y ago
From their news page: 24-Jun-2014: Team status changes including six new development team members The article listed links to: https://www.openssl.org/about/ https://www.openssl.org/about/ Hopefully the new team can deliver on the promise in this roadmap.
- leccine 12y ago
  Absolutely, there is a book written about this topic. http://en.wikipedia.org/wiki/The_Mythical_Man-Month http://en.wikipedia.org/wiki/The_Mythical_Man-Month
InfiniteRand 12y ago
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
- anaphor 12y ago
  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.
snvzz 12y ago
I don't expect much to come from rewarding failure. Throwing money away at OpenSSL isn't suddenly gonna make its developers good. I'll be running LibReSSL, and I expect most Linux distributions to do the same by default once the Linux port is released.
- cnst 12y ago
  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.
  - viraptor 12y ago
    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.
    - cnst 12y ago
      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.
- privong 12y ago
  > 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.
- 12y ago
erichurkman 12y ago
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.
- lockes5hadow 12y ago
  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.
tedunangst 12y ago
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.
- akjj 12y ago
  Sounds like OpenSSL is keeping FIPS in a refactored form and LibreSSL is getting rid of it.

70 points by dankohn1 12y ago

nodata 12y ago

So now we have a third refactor?

Twirrim 12y ago
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.
ihsw 12y ago
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). Things are looking up, IMO.
Strilanc 12y ago
This problem is important enough to justify multiple attempts in parallel, despite the redundant work.

ayrx 12y ago

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. This definitely increases my confidence in them.

josephlord 12y ago

From their news page: 24-Jun-2014: Team status changes including six new development team members The article listed links to: https://www.openssl.org/about/ https://www.openssl.org/about/ Hopefully the new team can deliver on the promise in this roadmap.

leccine 12y ago
Absolutely, there is a book written about this topic. http://en.wikipedia.org/wiki/The_Mythical_Man-Month http://en.wikipedia.org/wiki/The_Mythical_Man-Month

InfiniteRand 12y ago

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

anaphor 12y ago
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.

snvzz 12y ago

I don't expect much to come from rewarding failure. Throwing money away at OpenSSL isn't suddenly gonna make its developers good. I'll be running LibReSSL, and I expect most Linux distributions to do the same by default once the Linux port is released.

cnst 12y ago
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.
- viraptor 12y ago
  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.
  - cnst 12y ago
    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.
privong 12y ago
> 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.
12y ago

erichurkman 12y ago

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.

lockes5hadow 12y ago
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.

tedunangst 12y ago

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.

akjj 12y ago
Sounds like OpenSSL is keeping FIPS in a refactored form and LibreSSL is getting rid of it.