OpenSSL speeds up development to avoid being “slow-moving and insular”

Post-Heartbleed changes aim to improve security and code review.

Jon Brodkin – Jul 2, 2014 11:48 am | 38

Credit: Aurich Lawson / Thinkstock

The makers of OpenSSL unveiled a new development roadmap this week, saying the open source project needs to change because it “is increasingly perceived as slow-moving and insular.”

The inner workings of the poorly funded OpenSSL project came under scrutiny after the discovery of Heartbleed, a security flaw in the cryptography library that put much of the Web’s encrypted communications at risk. Tech giants eventually agreed to give the project money, enough to hire two full-time developers and perform a third-party security audit.

The new OpenSSL Project Roadmap, unveiled Monday and updated yesterday, sets out a list of goals for its new staff.

The project has numerous problems, the roadmap says. These include a backlog of bug reports, incomplete and incorrect documentation, code complexity that causes maintenance problems, inconsistent coding style, a lack of code review, and having no clear release plan, platform strategy, or security strategy.

The plan is to fix all these problems. For example, bug reports should receive “an initial response within four working days.” That goal can be met now, the roadmap says, but others will take longer. Defining a clear coding standard for the project is expected to take about three months. “Review[ing] and revis[ing] the public API with a view to reducing complexity” will take about a year.

As for reviewing code submitted to the project, the plan is to develop a process ensuring “that all new commits should first be reviewed by a team member conversant with the relevant code and updated until the reviewer’s issues are addressed.” This should be achieved within three months.

Besides the external security audit, the OpenSSL Project also intends to “[r]egularly audit the code using appropriate analysis tools,” starting within six months.

A new release strategy will cover how long each release should be supported and include steps to avoid security problems. “We need security fix releases with [a] very low chance of breaking anything,” the roadmap says. “This is largely met by prohibiting new features in stable branches.” Additionally, “If something is broken in a release a fixed version should be made available shortly afterwards,” and “[w]e need a way to get new binary compatible features into OpenSSL relatively quickly.”

The new “platform strategy” will target Linux and FreeBSD as the primary platforms, the ones where most development occurs. There will be a list of secondary platforms that are also supported.

The new “security strategy” sounds fairly simple. It will consist of a policy on “[h]ow we make security fixes” and “[w]hat (if any) pre-notification of forthcoming security releases will be provided (and to whom).” This should be implemented within two months.

OpenSSL developers are also evaluating a variety of potential features including support for IPv6 and hardware platforms like ARMv8 and POWER8, but the main focus will be on fixing the major problems identified after HeartBleed.