It’s been a rough couple of months for OpenSSL, the open-source SSL/TLS toolkit that runs the underlying encryption mechanisms for a large portion of the Internet. Back in April, the Heartbleed bug ravaged OpenSSL, which led to Heartbleed hysteria and widespread criticism of the small development team tasked with maintaining the vital protocol.

In the months since, the software industry came to OpenSSL’s rescue, and the project is finally beginning to right itself. With the help of the coalition of tech companies behind the Core Infrastructure Initiative, and aid from OpenBSD in the form of the forked LibReSSL encryption scheme, Open SSL has published a project road map laying out the project’s current issues, objectives and strategies going forward.

“The OpenSSL project is increasingly perceived as slow-moving and insular,” the document stated. “This road map will attempt to address this by setting out some objectives for improvement, along with defined timescales.”

The living document lays out a number of issues plaguing OpenSSL and translates them into primary plans of action. Each comes with an approximate timeframe as to when the issue will be resolved. The main issues and objectives are:

1. RT backlog: The log of open tickets in the OpenSSL bug tracking system (RT) has been backed up for years.

Objectives: Respond to tickets within four working days. (Timeframe: Now.)
Reduce existing RT backlog, including tickets raised before release of current versions. (Timeframe: Ongoing.)

2. Incomplete/incorrect documentation: Documentation of OpenSSL is patchy at best. Some areas are well documented, while many others suffer from incomplete or incorrect documentation.

Objective: Provide complete documentation for all public APIs, which may include introduction of a new documentation system. (Timeframe: Within one year.)

3. Library complexity: Code has been ported to a large number of no-longer-relevant platforms, complicating the codebase. FIPS support also complicates the library and causes maintenance and user problems.

Objectives: Review and revise the public API, review and refactor FIPS code. (Timeframe: Within one year.)
Document a platform strategy. (Timeframe: Within three months.)
Review and refactor the memory management code. (Timeframe: Within six months.)

4. Inconsistent coding style: Numerous developers and coding styles in the codebase have created an unusual and idiosyncratic code layout unlike other open-source software.

Objective: Define a clear coding standard and format codebase, covering code layout as well as platform dependencies, unit testing and optional code. (Timeframe: Within three months.)

5. Lack of code review: There are no code-review system or mandatory code reviews.

Objective: Implement a process to allow a team member familiar with relevant code to review and approve all new commits. (Timeframe: Within three months.)
Agree on a code-review system. (Timeframe: Within six months.)
Externally audit the current codebase. (Timeframe: Dependent on external body.)

6. No clear release plan: OpenSSL has released new features on an infrequent basis, and no forward plan of releases has been published, complicating user planning for new features or support. The OpenSSL development team also diverts effort maintaining stable releases.

Objective: Develop a release strategy for frequency and dates of releases, length of support, and end of life. The release strategy also includes low-risk security fix releases, plans to implement binary-compatible features, and a way to refactor code and make binary-incompatible changes. (Timeframe: Within three months.)

7. No clear platform strategy: In supporting a wide range of platforms, OpenSSL code has become cluttered and difficult to maintain. Code still supports legacy platforms, and the development team does not have access to many of the supported platforms.

Objective: Moving forward OpenSSL will adopt the following policy:
• There will be a defined set of primary platforms. The primary platforms will be Linux and FreeBSD. A primary platform is one where most development occurs.
• In addition, there will be a list of secondary platforms, which are supported by the development team.
• Platform-specific code will be moved out of the main codebase (removing overuse of “ifdef”).
• Legacy platforms that are unlikely to have wide deployment will be removed from the code.
• Non-supported platforms requiring regular maintenance activities will eventually be removed from the code after first seeking community owners to support the platforms in platform-specific repositories.

8. No published security strategy: No well-known approach to disseminate security advisories.

Objective: Document a security strategy that defines how to make security fixes and what notifications of forthcoming security fixes will be provided. (Timeframe: Within two months.)

9. New features: While the OpenSSL project’s main focus will be on resolving the issues above, it is also evaluating the addition of several new features, including:
• IPv6 support
• AEAD updates (API review, Poly/ChaCha support, /dev/crypto operations coalescing)
• Support for new cipher suites
• Extended SSL_CONF support
• DANE support
• Security levels (currently experimental in master)
• OCB
• FIPS code review and refactor
• Support for emerging platforms such as ARMv8 and POWER8
• Built-in MT support for two major threading “flavors,” POSIX threads and Win32