- Apr 24, 2013
- 1,200
It's almost three months since the Heartbleed bug became public, after which the sad state of OpenSSL, the overwhelmingly dominant TLS/SSL library on the Internet, became common knowledge. Now the OpenSSL project has released a roadmap document describing the problems with the software and their plans to address them.
The list resembles lists made by many others in the wake of Heartbleed, meaning it pulls no punches. Nor does it pretend to promise quick progress: "Objectives and dates should be considered aspirational."
Crypto insiders had, for years, complained of the poor organization, unreadable code, almost complete lack of documentation, and other problems with OpenSSL. It was enough that the OpenBSD project decided to fork the OpenSSL code into a separate project they call LibreSSL.
Some of the issues raised in the document are:
Specific areas of the code, including memory management and the infamous FIPS support, will be reviewed and revised within a year or sooner. Plans for code review, audit, style guidelines and a release strategy will be developed within months.
Some serious thought will be put into which platforms to support. OpenSSL supports an excessive list of platforms. Many critics question the need for a Windows version, as it complicates the code and Windows developers largely use the operating system API.
It is, in a sense, inspiring to see the developers in charge lay bare the awful truth, but for developers that can only go so far. Can anyone feel good about committing to a project which looks itself over and sees all this? Remember, the goals and timetables are "aspirational."
The one thing I personally see which inspires some confidence is the only bolded non-title text in the document: "An important principle is that the priority and focus of effort will be on achieving these objectives over and above the delivery of new features." No sense growing the attack surface when what you have is such a disaster.
Nevertheless, the document also lists some new features which the team would like to add when the time is right. Some of these look like major gaps in the current software, such as IPv6 support, ARM support and multithreading.
It's true I don't have a good feeling about this project, but I do wish them well. When we look for software on the Internet which qualifies as "critical infrastructure," OpenSSL is at or near the top of the list. Let's hope they accomplish some of these goals before the next Heartbleed emerges.
The list resembles lists made by many others in the wake of Heartbleed, meaning it pulls no punches. Nor does it pretend to promise quick progress: "Objectives and dates should be considered aspirational."
Crypto insiders had, for years, complained of the poor organization, unreadable code, almost complete lack of documentation, and other problems with OpenSSL. It was enough that the OpenBSD project decided to fork the OpenSSL code into a separate project they call LibreSSL.
Some of the issues raised in the document are:
- The bug tracking system is overloaded with open tickets, a large proportion of which "...have been open for years." Some of these bugs have actually been fixed, but nobody bothered to record the fact in the system.
- The documentation stinks. Not uniformly, but largely.
- The complexity and poor organization of the code and lack of a consistent coding style make it quite difficult to maintain. The public API contains interfaces which should probably be private; fixing that now runs the risk of breaking applications.
- There is no code review system. None.
Specific areas of the code, including memory management and the infamous FIPS support, will be reviewed and revised within a year or sooner. Plans for code review, audit, style guidelines and a release strategy will be developed within months.
Some serious thought will be put into which platforms to support. OpenSSL supports an excessive list of platforms. Many critics question the need for a Windows version, as it complicates the code and Windows developers largely use the operating system API.
It is, in a sense, inspiring to see the developers in charge lay bare the awful truth, but for developers that can only go so far. Can anyone feel good about committing to a project which looks itself over and sees all this? Remember, the goals and timetables are "aspirational."
The one thing I personally see which inspires some confidence is the only bolded non-title text in the document: "An important principle is that the priority and focus of effort will be on achieving these objectives over and above the delivery of new features." No sense growing the attack surface when what you have is such a disaster.
Nevertheless, the document also lists some new features which the team would like to add when the time is right. Some of these look like major gaps in the current software, such as IPv6 support, ARM support and multithreading.
It's true I don't have a good feeling about this project, but I do wish them well. When we look for software on the Internet which qualifies as "critical infrastructure," OpenSSL is at or near the top of the list. Let's hope they accomplish some of these goals before the next Heartbleed emerges.
