'I don't want to go on the cart' ... OpenSSL revived with survival roadmap
Heartbleed-battered crypto library reveals long path back to health
The OpenSSL project, having suffered sharp criticism following the revelation of a string of serious security vulnerabilities, has published a roadmap explaining how it plans to address users' concerns.
"The OpenSSL project is increasingly perceived as slow-moving and insular," the intro to the document states. "This roadmap will attempt to address this by setting out some objectives for improvement, along with defined timescales."
The document begins by identifying a number of known issues with the project, including problems both with processes and with the code itself.
Essentially, the OpenSSL team admits that its current source code tree is a mess. It's a complex project, but it lacks a consistent coding style and there are no formal processes in place for code review. As a result, its code has grown cluttered and difficult to maintain. Worse, the documentation is described as "patchy at best" and some of it is inaccurate.
It doesn't help that so far the development team has lacked a long-term game plan. New versions are released infrequently and no release schedule has ever been published. Open tickets have been piling up in the project's Request Tracker database, with some lingering for years.
No strategy for maintaining the code base
What's more, the development team admits that it has had no strategy for maintaining the code base across the many platforms to which it has been ported. Some are legacy platforms and the developers currently have no access to them, so there's no telling whether today's code still runs on them.
Finally, OpenSSL has never defined a formal approach for notifying the public about security advisories. OpenBSD founder Theo De Raadt has even accused the OpenSSL developers of intentionally withholding information about important security fixes in the library from the OpenBSD project – but given the admissions in the OpenSSL roadmap, El Reg suspects that was a matter more of neglect than of malice.
None of this should come as a surprise to anyone who has been following the fallout from the Heartbleed vulnerability scandal. Most of the same issues were raised by de Raadt – albeit less politely – when he decided to fork OpenSSL as LibReSSL in April.
The LibreSSL project is ongoing, but OpenSSL may have more resources to throw at a clean-up effort, particularly in light of the increased attention the project has received from big companies and the Linux Foundation, post-Heartbleed.
The roadmap doesn't offer solutions to most of the aforementioned problems. Those still need to be discussed and agreed upon, with decisions to be made in various timeframes, ranging from three months to six months or a year – although we're warned that those estimates are "aspirational."
But the project's platform policy has already begun to coalesce. Henceforth, the primary development platforms for OpenSSL will be Linux and FreeBSD. A list of supported secondary platforms is yet to be decided, but once it is, support for legacy platforms will be retired and their code will be pared out of the main tree. This process will begin, the roadmap says, "based on how quickly we can refactor the code."
And even with all this work ahead of them, the OpenSSL developers say they are, in fact, evaluating new features – among them IPv6 support, support for ARMv8 and other emerging platforms, and built-in support for POSIX and Win32 multithreading. Don't hold your breath on these, though; for the time being, fixing the project itself is Job One. ®
Sponsored: Hyper-scale data management