OpenSSL    
 General |  Contacts |  Credits |  Roadmap |  Security Policy 
 
Title
FAQ
About
News
Documents
Source
Support
Related
Security

 

OpenSSL Project Roadmap

First issued 30th June 2014

Last modified 8th September 2014


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.

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)

  1. 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)

    1. This may include introducing a new documentation system

    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).

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)

  4. Review and refactor the memory management code (Timescale: Within six months)

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)

  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)

Audit

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

Static/Dynamic Analysis

  1. 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.

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

  • 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)

  • 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 MT 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-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.