OpenSSL Project Roadmap
First issued 30th June 2014
Last modified 16th July 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.
The OpenSSL project is currently experiencing a number of issues.
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.
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.
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.
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.
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.
Lack of code review
We don't have a code review system
and we don't mandate code reviews.
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.
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
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)
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.
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
Manage all newly submitted RT tickets in a timely manner such as an
initial response within four working days. (Timescale: Now)
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
Provide complete documentation for all of the public API (excluding
deprecated APIs) (Timescale: Within one year)
This may include introducing a new documentation system
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).
Review and revise the public API with a view to reducing complexity
(Timescale: Within one year)
Document a platform strategy: see below (Timescale: Within three
Review and refactor the FIPS code to make it far less intrusive
(Timescale: Within one year)
Review and refactor the memory management code (Timescale: Within
Inconsistent coding style
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
Format the entire codebase according to the agreed standard.
(Timescale: Within three months of coding standard being defined)
Refactor code to follow other parts of the style guide. (Timescale:
Within one year)
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
Agree on a code review system. (Timescale: Within six months)
Externally audit the current code base. (Timescale: Dependent on
Regularly audit the code using appropriate analysis tools.
(Timescale: Within six months)
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:
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).
If something is broken in a release a fixed version should be made
available shortly afterwards (i.e. more letter releases more often)
We need a way to get new binary compatible features into OpenSSL
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
We need a way to refactor code and make necessary binary
incompatible changes, deprecating APIs etc.
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
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
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
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.
We will be documenting a security strategy which will define our
The primary focus of effort will be on achieving the objectives
detailed above, however we are evaluating the following new features.
AEAD updates (API review, Poly/ChaCha support, /dev/crypto
Support for new ciphersuites e.g. CCM.
Extended SSL_CONF support.
Security levels (currently experimental in master)
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
| || |