Remove needless #wml lines

[openssl-web.git] / about / roadmap.wml

#use wml::openssl area=about page=roadmap

<title>About, Roadmap</title>
<h1><center>OpenSSL Project Roadmap</center></h1>
<h2><center>First issued 30th June 2014</center></h2>
<h2><center>Last modified 14th October 2014</center></h2>
<p>
<br>
</p>
<p>
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.</p>
<p>
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.</p>
<h1>Current Issues</h1>
<p>
The OpenSSL project is currently experiencing a number of issues.
These are:</p>
<ol>
        <li><p>
        <b>RT Backlog<br></b><br>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.<br><br>
        </p>
        <li><p>
        <b>Incomplete/incorrect documentation<br><br></b>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.<br><br>
        </p>
        <li><p>
        <b>Library complexity<br><br></b>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.<br><br>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.<br><br>The current memory management code has
        also been a source of problems and vulnerabilities.<br><br>
        </p>
        <li><p>
        <b>Inconsistent coding style<br><br></b>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.<br><br>
        </p>
        <li><p>
        <del>
        <b>Lack of code review<br><br></b>We don't have a code review system
        and we don't mandate code reviews.<br><br>
        </del>
        </p>
        <li><p>
        <b>No clear release plan<br><br></b>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.<br><br>
        </p>
        <li><p>
        <b>No clear platform strategy</b><br><br>Historically OpenSSL has
        supported a very wide range of platforms. Typically platform support has
        been added through &quot;ifdef&quot; conditional compilation on a per
        platform basis. This approach has led to a number of problems:</p>
</ol>
<ul>
        <li><p>
        The code has become very cluttered and is difficult to effectively
        maintain</p>
        <li><p>
        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</p>
        <li><p>
        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)<br><br>
        </p>
</ul>
<del>
<ol start="8">
        <li><p>
        <b>No published security strategy</b><br><br>We do not have a well-known
        and published approach for how we appropriately inform all interested
        parties of security advisories.<br><br>
        </p>
</ol>
</del>

<h1>Objectives</h1>
<p>
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.</p>
<p>
<b>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.</b></p>
<h2>RT Backlog</h2>
<ol>
        <li><p>
        Manage all newly submitted RT tickets in a timely manner such as an
        initial response within four working days. (Timescale: Now)</p>
        <li><p>
        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</p>
        <a name="8-sep-2014"><p>Update (8th September 2014):</a>
        we have made a great deal of progress on the backlog.
        A <a href="ticket-activity.png">graph of ticket activity</a>
        is available, as is the <a href="buglist.txt">raw data</a>
        for every bug showing when it was open, and resolved. We will
        update these files periodically.</a>
</ol>
<h2>Incomplete/incorrect documentation</h2>
<ol>
        <li><p>
        Provide complete documentation for all of the public API (excluding
        deprecated APIs) (Timescale: Within one year)</p>
        <ol type="a">
                <li><p>
                This may include introducing a new documentation system</p>
                <li><p>
                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).</p>
        </ol>
</ol>
<h2>Library complexity</h2>
<ol>
        <li><p>
        Review and revise the public API with a view to reducing complexity
        (Timescale: Within one year)</p>
        <li><p>
        Document a platform strategy: see below (Timescale: Within three
        months)</p>
        <li><p>
        Review and refactor the FIPS code to make it far less intrusive
        (Timescale: Within one year)</p>
        <li><p>
        Review and refactor the memory management code (Timescale: Within
        six months)</p>
</ol>
<h2>Inconsistent coding style</h2>
<ol>
        <li><p>
        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)
        </p>
        <li><p>
        Format the entire codebase according to the agreed standard.
        (Timescale: Within three months of coding standard being defined)
        </p>
        <li><p>
        Refactor code to follow other parts of the style guide. (Timescale:
        Within one year)</p>
</ol>
<h2>Code review</h2>
<ol>
        <li><p>
        <del>
        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)</p>
        </del>
        <p>
        Objective met (16th July 2014): All changes are first reviewed by 
        another team member prior to being committed to the public openssl 
        repository.
        </p>
        <li><p>
        Agree on a code review system. (Timescale: Within six months)</p>
</ol>
<h2>Audit</h2>
<ol>
        <li><p>
        Externally audit the current code base. (Timescale: Dependent on
        external body)</p>
        <p>
        <p>Update (14th October 2014):
        Auditors selected and funded; schedule being worked on.</p>
</ol>
<h2>Static/Dynamic Analysis</h2>
<ol>
        <li><p>
        Regularly audit the code using appropriate analysis tools.
        (Timescale: Within six months)
        </p>
</ol>
<h2><a name="relstrat">Release Strategy</a></h2>
<p>
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)</p>
<p>
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:</p>
<ol>
        <li><p>
        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).</p>
        <li><p>
        If something is broken in a release a fixed version should be made
        available shortly afterwards (i.e. more letter releases more often)</p>
        <li><p>
        We need a way to get new binary compatible features into OpenSSL
        relatively quickly.</p>
        <li><p>
        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</p>
        <li><p>
        We need a way to refactor code and make necessary binary
        incompatible changes, deprecating APIs etc.</p>
</ol>
<h2><a name="platstrat">Platform Strategy</a></h2>
<p>
Moving forward OpenSSL will adopt the following policy:</p>
<ul>
        <li><p>
        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.</p>
        <li><p>
        In addition there will be a list of secondary platforms which are
        supported by the development team.</p>
        <li><p>
        Platform specific code will be moved out of the main codebase
        (removing overuse of &quot;ifdef&quot;).</p>
        <li><p>
        Legacy platforms that are unlikely to have wide deployment will be
        removed from the code.</p>
        <li><p>
        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.<br><br></p>
</ul>
<p>
Necessary criteria for a platform to be included in the secondary
platform list includes:</p>
<ul>
        <li><p>
        Currency, i.e. a platform is widely deployed and in current use</p>
        <li><p>
        Vendor support</p>
        <li><p>
        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</p>
        <li><p>
        Dev team ownership, i.e. at least one person on the team is willing
        to take some responsibility for a platform<br><br></p>
</ul>
<p>
In addition the secondary list will be as small as possible so as not
to spread the development team too thinly.</p>
<p>
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.</p>
<p>
The Platform Strategy will be phased in over a period of time based
on how quickly we can refactor the code.</p>
<h2>Security Strategy</h2>
<del>
<p>
We will be documenting a security strategy which will define our
policy on:</p>
<ul>
        <li><p>
        How we make security fixes</p>
        <li><p>
        What (if any) pre-notification of forthcoming security releases will
        be provided (and to whom) (Timescale: Within two months)</p>
</ul>
</del>
<p>
Objective met (7th September 2014): The OpenSSL security policy is available
<a href="secpolicy.html">here</a>
</p>
<h1>Forthcoming Features</h1>
<p>
The primary focus of effort will be on achieving the objectives
detailed above, however we are evaluating the following new features.</p>
<ul>
        <li><p>
        IPv6 support</p>
        <li><p>
        AEAD updates (API review, Poly/ChaCha support, /dev/crypto
        operations coalescing)</p>
        <li><p>
        TLS 1.3.
        </p>
        <li><p>
        Certificate Transparency support.
        </p>
        <li><p>
        Support for new ciphersuites e.g. CCM.</p>
        <li><p>
        Extended SSL_CONF support.</p>
        <li><p>
        DANE support.</p>
        <li><p>
        Security levels (currently experimental in master)</p>
        <li><p>
        OCB</p>
        <li><p>
        FIPS code review and refactor</p>
        <li><p>
        Support for emerging platforms, e.g. ARMv8, POWER8</p>
        <li><p>
        Built-in MT support for two major threading "flavours", POSIX
        threads and Win32.</p>
</ul>

<h1>Roadmap Update History</h1>
<p>
The following changes have been made since the roadmap was first 
issued 30-June-2014.
</p>
<ul>
        <li><p>
        <a name="14-oct-2014">14-October-2014.</a>
        Updated audit; added TLS 1.3 and Certificate
        Transparency to features.</p>
        <li><p>
        8-September-2014. Updated status on the RT backlog objective.</p>
        <li><p>
        7-September-2014. Updated security policy section.</p>
        <li><p>
        16-July-2014. Updated code review section.</p>
        <li><p>
        1-July-2014. Noted RT is our bug tracking system.</p>
</ul>