This document is intended to outline the OpenSSL project roadmap. It is a living document and is expected to change over time. Objectives and dates should be considered aspirational.

The OpenSSL project is increasingly perceived as slow-moving and insular. This roadmap will attempt to address this by setting out some objectives for improvement, along with defined timescales.

Table of Contents:

1. Current Issues
2. Objectives
3. Forthcoming Features
4. Roadmap Update History

 

Current Issues

The OpenSSL project is currently experiencing a number of issues. These are:

1. RT Backlog
   Over a period of some considerable time open tickets have been building up in RT (our bug tracking system) to the point that now there are a very significant number of them. A large proportion of these issues have been open for years. Some of these have in fact been dealt with and should be closed, but this has not been recorded in the system. Most however have not been looked at.
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. There are also many areas which have no documentation at all.
3. Library complexity
   The OpenSSL libraries and applications are complex, both from a maintainer's perspective and from a user's perspective. The public API contains many things which should probably be internal. The code has been ported to a large number of platforms, many of which are no longer relevant to us today, and this complicates the codebase. Some parts of the code have been in place for a very long time, and are in need of a refresh. It is further complicated by the support for FIPS. This complexity causes maintenance problems, and can also be the source of obscure and difficult to spot security vulnerabilities. It can also make users' lives much more difficult especially when combined with (2) above. The current memory management code has also been a source of problems and vulnerabilities.
4. Inconsistent coding style
   There have been numerous developers working on the codebase over many years. There are many different styles used within the code, which is confusing and makes maintenance more difficult than it should be. Even if strictly consistent, the current code layout is unusual and idiosyncratic and unlike any other open source software.
5. Lack of code review
   We don't have a code review system and we don't mandate code reviews.
6. No clear release plan
   Historically OpenSSL has made new feature releases on an infrequent basis and no forward plan of releases has been published. It is difficult for users to plan for new releases, and understand when new features might become available, or when support will end for a release. In addition a large number of stable releases are maintained by the OpenSSL development team - diverting effort away from the most up to date versions.
7. No clear platform strategy
   Historically OpenSSL has supported a very wide range of platforms. Typically platform support has been added through "ifdef" conditional compilation on a per platform basis. This approach has led to a number of problems:
   • The code has become very cluttered and is difficult to effectively maintain
   • There is support still in the code for a number of legacy platforms which are unlikely to be widely deployed today - if the code even still works on those platforms
   • In practice the development team do not have access to many of the platforms that the codebase supports and testing typically takes place on a very limited set (usually Linux, FreeBSD and Windows)
8. No published security strategy
   We do not have a well-known and published approach for how we appropriately inform all interested parties of security advisories.

Objectives

Each of the issues identified above can be translated into high level objectives. Some of these objectives can be achieved more easily and quickly than others.

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.

RT Backlog

1. Manage all newly submitted RT tickets in a timely manner such as an initial response within four working days. (Timescale: Now)
2. Reduce over time the existing RT backlog (Timescale: Ongoing). This may include the mass closure of very old tickets, such as those raised before the release of any currently supported version.

   Update (8th September 2014): we have made a great deal of progress on the backlog. A graph of ticket activity is available, as is the raw data for every bug showing when it was open, and resolved. We will update these files periodically.

Incomplete/incorrect documentation

1. Provide complete documentation for all of the public API (excluding deprecated APIs) (Timescale: Within one year).
2. Some parts of the API have historically been public but were not intended for public use, such as low level cipher and digest APIs. These parts may not be documented, and if they are will be marked as deprecated (Timescale: within nine months).
3. This may include introducing a new documentation system.

Library complexity

1. Review and revise the public API with a view to reducing complexity (Timescale: Within one year)
2. Document a platform strategy: see below (Timescale: Within three months)
3. Review and refactor the FIPS code to make it far less intrusive (Timescale: Within one year)
   Objective met (2015): The FIPS code has been removed from the master branch, and will be re-integrated more cleanly during a future validation.
4. Review and refactor the memory management code. (Timescale: Within six months)
   Objective met (2015): All use of dynamic memory allocation has been cleaned up and made consistent, and the internal memory pool has been removed.

Inconsistent coding style

1. Define a clear coding standard for the project. This will cover not only code layout but also items such as how to handle platform dependencies, unit testing and optional code. (Timescale: Within three months).
2. Format the entire codebase according to the agreed standard. (Timescale: Within three months of coding standard being defined).
   Objective met (2015): All release branches were reformatted using a script included in the release.
3. Refactor code to follow other parts of the style guide. (Timescale: Within one year)

Code review

1. Agree and implement a process such 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 is contingent on recruiting sufficient team members that reviewers are more-or-less always available. (Timescale: Within three months)
   Objective met (16th July 2014): All changes are first reviewed by another team member prior to being committed to the public openssl repository.
2. Agree on a code review system. (Timescale: Within six months)
   Objective met (2015): We use GitLab.

Audit

Externally audit the current code base. (Timescale: Dependent on external body)

Update (14th October 2014): Auditors selected and funded; schedule being worked on.

Static/Dynamic Analysis

Regularly audit the code using appropriate analysis tools. (Timescale: Within six months)

Release Strategy

We intend to develop a release strategy which will set out our plans for how frequently we plan to release, and when. It will also cover how long releases will be supported for, and when their EOL (End Of Life) will be. (Timescale: Within three months)

There are a number of objectives that we would be seeking to address within the release strategy. Some of these objectives compete with each other, and so from necessity there will have to be compromises. The objectives are:

1. We need security fix releases with very low chance of breaking anything. This is largely met by prohibiting new features in stable branches (i.e. letter releases).
2. If something is broken in a release a fixed version should be made available shortly afterwards (i.e. more letter releases more often)
3. We need a way to get new binary compatible features into OpenSSL relatively quickly.
4. We don't want to have to maintain too many branches. This is likely to include a timescale for the EOL of version 0.9.8
5. We need a way to refactor code and make necessary binary incompatible changes, deprecating APIs etc.

Objective met (2015): We have announced a release strategy which includes end-of-life and long-term support definitions. Also, our security policy has relevant information.

Platform Strategy

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.

Necessary criteria for a platform to be included in the secondary platform list includes:

• Currency, i.e. a platform is widely deployed and in current use
• Vendor support
• Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues
• Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform.

In addition the secondary list will be as small as possible so as not to spread the development team too thinly.

The secondary platforms are still to be defined but will be based on the above criteria. For each primary/secondary platform, we should have, at least, a continuous integration box and a dev machine we can access for test/debug. We will seek support from the platform vendors or the community to provide access to these platforms. The secondary platform list will change over time, but an initial list will be produced within three months.

The Platform Strategy will be phased in over a period of time based on how quickly we can refactor the code.

Security Strategy

We will be documenting a security strategy which will define our policy on how we make security fixes, and what (if any) pre-notification of forthcoming security releases will be provided (and to whom) (Timescale: Within two months)
Objective met (7th September 2014): The OpenSSL security policy is available here.

Forthcoming Features

The primary focus of effort will be on achieving the objectives detailed above, however we are evaluating the following new features.

• IPv6 support
• AEAD updates (API review, Poly/ChaCha support, /dev/crypto operations coalescing)
• TLS 1.3.
• Certificate Transparency support
• Support for new ciphersuites e.g., CCM
• Extended SSL_CONF support
• DANE support
• Security levels (currently experimental in master)
• OCB
• FIPS code review and refactor
• Support for emerging platforms, e.g. ARMv8, POWER8
• Built-in multi-threaded support for two major threading "flavours," POSIX threads and Win32

Roadmap Update History

The following changes have been made since the roadmap was first issued 30-June-2014.

• 8-August-2015. Many updates, for what happened in 2015.
• 14-October-2014. Updated audit; added TLS 1.3 and Certificate Transparency to features.
• 8-September-2014. Updated status on the RT backlog objective.
• 7-September-2014. Updated security policy section.
• 16-July-2014. Updated code review section.
• 1-July-2014. Noted RT is our bug tracking system.