<!DOCTYPE html>
<html lang="en">
-<!--#include virtual="/inc/head.shtml" -->
-
-<body>
-<!--#include virtual="/inc/banner.shtml" -->
-
-<div id="main">
- <div id="content">
- <div class="blog-index">
- <article>
- <header>
- <h2>Project Roadmap</h2>
- <h5>
- First issued 30th June 2014<br/>
- Last modified 8th August 2015
- </h5>
- </header>
-
- <div class="entry-content">
- <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>
-
- <h3><a name='toc'>Table of Contents:</a></h3>
-
- <ol>
- <li><a href="#current">Current Issues</a></li>
- <li><a href="#objectives">Objectives</a></li>
- <li><a href="#forthcoming">Forthcoming Features</a></li>
- <li><a href="#update">Roadmap Update History</a></li>
- </ol></p>
- <p> </p>
-
-
- <h3><a name="current">Current Issues</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
- <p>
- The OpenSSL project is currently experiencing a number of issues.
- These are:</p>
- <ol>
- <li><em>RT Backlog</em><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.
- </li>
- <li><em>Incomplete/incorrect documentation</em><br/>
- 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.
- </li>
- <li><em>Library complexity</em><br/>
- 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.
- </li>
- <li><em>Inconsistent coding style</em><br/>
- 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.
- </li>
- <li><em>Lack of code review</em><br/>
- We don't have a code review system and we don't mandate code
- reviews.
- </li>
- <li><em>No clear release plan</em><br/>
- 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.
- </li>
- <li><em>No clear platform strategy</em><br/>
- 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:
- <ul>
- <li>
- The code has become very cluttered and is difficult to
- effectively maintain</li>
- <li>
- 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</li>
- <li>
- 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)</li>
- </ul>
- <del>
- <li>
- <em>No published security strategy</em><br/>
- We do not have a well-known and published approach for how we
- appropriately inform all interested parties of security
- advisories.</li>
- </del>
- </ol>
-
- <p></p>
-
- <h3><a name="objectives">Objectives</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
- <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>
- <em>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.</em></p>
-
- <h4>RT Backlog</h4>
- <ol>
- <li>
- This is being revised.
- </li>
- </ol>
-
- <h4>Incomplete/incorrect documentation</h4>
- <ol>
- <li>
- Provide complete documentation for all of the public
- API (excluding deprecated APIs) (Timescale: Within one year).
- </li>
- <li>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).</li>
- <li>This may include introducing a new documentation system.</li>
- </ol>
-
- <h4>Library complexity</h4>
- <ol>
- <li>
- Review and revise the public API with a view to reducing complexity
- (Timescale: Within one year)</li>
- <li>
- Document a platform strategy: see below (Timescale: Within three
- months)</li>
- <li>
- <del>Review and refactor the FIPS code to make it far less
- intrusive (Timescale: Within one year)</del>
- <br>Objective met (2015): The FIPS code has been removed from the
- master branch, and will be re-integrated more cleanly during
- a future validation.
- </li>
- <li>
- <del>Review and refactor the memory management code.
- (Timescale: Within six months)</del>
- <br>Objective met (2015): All use of dynamic memory allocation has
- been cleaned up and made consistent, and the internal memory
- pool has been removed.
- </li>
- </ol>
-
- <h4>Inconsistent coding style</h4>
- <ol>
- <li>
- 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).</li>
- <li>
- <del>Format the entire codebase according to the agreed standard.
- (Timescale: Within three months of coding standard being
- defined).</del>
- <br>Objective met (2015): All release branches were
- reformatted using a script included in the release.
- </li>
- <li>
- Refactor code to follow other parts of the style guide. (Timescale:
- Within one year)</li>
- </ol>
-
- <h4>Code review</h4>
- <ol>
- <li>
- <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)
- </del>
- <br>Objective met (16th July 2014): All changes are first reviewed by
- another team member prior to being committed to the public openssl
- repository.
- </li>
- <li>
- <del>
- Agree on a code review system. (Timescale: Within six months)
- </del>
- <br>Objective met (2015): We use
- <a href="https://gitlab.com">GitLab</a>.
- </li>
- </ol>
-
- <h4>Audit</h4>
- <p>
- Externally audit the current code base. (Timescale: Dependent on
- external body)</p>
- <p>Update (14th October 2014):
- Auditors selected and funded; schedule being worked on.</p>
-
- <h4>Static/Dynamic Analysis</h4>
- <p>
- Regularly audit the code using appropriate analysis tools.
- (Timescale: Within six months)
- </p>
-
- <h4>Release Strategy</h4>
- <del>
- <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:
- <ol>
- <li>
- 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).</li>
- <li>
- If something is broken in a release a fixed version should be made
- available shortly afterwards (i.e. more letter releases more
- often)</li>
- <li>
- We need a way to get new binary compatible features into OpenSSL
- relatively quickly.</li>
- <li>
- 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</li>
- <li>
- We need a way to refactor code and make necessary binary
- incompatible changes, deprecating APIs etc.</li>
- </ol>
- </del>
- Objective met (2015): We have announced a
- <a href="releasestrat.html">release strategy</a>
- which includes end-of-life and long-term support definitions.
- Also, our
- <a href="secpolicy.html">security policy</a> has relevant
- information.
- </p>
-
- <h4>Platform Strategy</h4>
- <p>
- Moving forward OpenSSL will adopt the following policy:</p>
- <ul>
- <li>
- 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.</li>
- <li>
- In addition there will be a list of secondary platforms which are
- supported by the development team.</li>
- <li>
- Platform specific code will be moved out of the main codebase
- (removing overuse of "ifdef").</li>
- <li>
- Legacy platforms that are unlikely to have wide deployment will be
- removed from the code.</li>
- <li>
- 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.</li>
- </ul>
- <p>
- Necessary criteria for a platform to be included in the secondary
- platform list includes:</p>
- <ul>
- <li>
- Currency, i.e. a platform is widely deployed and in current use</li>
- <li>
- Vendor support</li>
- <li>
- 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</li>
- <li>
- Dev team ownership, i.e. at least one person on the team is willing
- to take some responsibility for a platform.</li>
- </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>
-
- <h4>Security Strategy</h4>
- <p>
- <del>
- 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)
- </del>
- <br>Objective met (7th September 2014): The OpenSSL security policy
- is available <a href="secpolicy.html">here</a>.
- </p>
-
- <h3><a name="forthcoming">Forthcoming Features</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
- <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>IPv6 support</li>
- <li>AEAD updates (API review, Poly/ChaCha support, /dev/crypto
- operations coalescing)</li>
- <li>TLS 1.3.</li>
- <li>Certificate Transparency support</li>
- <li>Support for new ciphersuites e.g., CCM</li>
- <li>Extended SSL_CONF support</li>
- <li>DANE support</li>
- <li>Security levels (currently experimental in master)</li>
- <li>OCB</li>
- <li>FIPS code review and refactor</li>
- <li>Support for emerging platforms, e.g. ARMv8, POWER8</li>
- <li>Built-in multi-threaded support for two major threading
- "flavours," POSIX threads and Win32</li>
- </ul>
- <p></p>
-
- <h3><a name="update">Roadmap Update History</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
- <p>
- The following changes have been made since the roadmap was first
- issued 30-June-2014.
- </p>
- <ul>
- <li>8-August-2015.
- Many updates, for what happened in 2015.</li>
- <li>14-October-2014.
- Updated audit; added TLS 1.3 and Certificate
- Transparency to features.</li>
- <li>8-September-2014.
- Updated status on the RT backlog objective.</li>
- <li>7-September-2014.
- Updated security policy section.</li>
- <li>16-July-2014.
- Updated code review section.</li>
- <li>1-July-2014.
- Noted RT is our bug tracking system.</li>
- </ul>
+ <!--#include virtual="/inc/head.shtml" -->
+
+ <body>
+ <!--#include virtual="/inc/banner.shtml" -->
+
+ <div id="main">
+ <div id="content">
+ <div class="blog-index">
+ <article>
+ <header>
+ <h2>Project Roadmap 2016-2017</h2>
+ <h5>
+ First issued 7th October 2016<br/>
+ Last modified 7th October 2016
+ </h5>
+ </header>
+
+ <div class="entry-content">
+ <p>
+ This document is the OpenSSL project
+ roadmap. It is a living document and is expected to change
+ over time. Objectives and dates should be considered
+ aspirational.</p>
+
+ <h3><a name='toc'>Table of Contents:</a></h3>
+
+ <ol>
+ <li><a href="#objectives">Objectives</a></li>
+ <li><a href="#forthcoming">Forthcoming Features</a></li>
+ </ol></p>
+
+ <h3><a name="objectives">Objectives</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
+ <p>
+ Some of these objectives can be achieved more easily and quickly
+ than others.</p>
+
+ <h4>TLS 1.3</h4>
+ <p>Interoperable implementation of client and server side
+ of the protocol (Timescale: Next feature release)</p>
+
+ <h4>FIPS</h4>
+ <p>Updated cryptographic module (Timescale: future
+ feature release)</p>
+
+ <h4>Issues Backlog</h4>
+ <ol>
+ <li>
+ Manage all newly submitted issues in a timely
+ manner. An initial classification occurs within two
+ weeks. (Timescale: Now)</li>
+ <li>
+ Reduce over time the existing issues backlog. This
+ may include the mass closure of very old tickets,
+ such as those raised before the release of any
+ currently supported version. (Timescale:
+ Ongoing)</li>
+ </ol>
+
+ <h4>Incomplete/incorrect documentation</h4>
+ <ol>
+ <li>
+ All new public API will be documented (Timescale: Now).
+ </li>
+ <li>
+ Provide improved documentation for all of the public
+ SSL APIs (excluding deprecated APIs) (Timescale:
+ Within one year).
+ </li>
+ </ol>
+
+ <h4>Improved testing</h4>
+ <ol>
+ <li>67% coverage as measured by Coveralls (Timescale: Within one year).</li>
+ <li>Significantly improved TLS protocol-level testing
+ (Timescale: Next feature release).</li>
+ </ol>
+
+ <h4>Platform Strategy</h4>
+ <ol>
+ <li>Classify all the platforms known by Configure
+ according to the
+ <a href="platformpolicy.html">platform policy</a>
+ (Timescale: Next feature release)</li>
+ <li>Publish the build and test status for each platform
+ (Timescale: Next feature release)</li>
+ </oL>
+
+ <h3><a name="forthcoming">Forthcoming Features</a> <a
+ href="#toc"><img src="/img/up.gif"/></a></h3>
+ <p><em>The primary focus of the next feature release is
+ TLS 1.3.</em></p>
+
+ <p>We are also evaluating the following new features.</p>
+
+ <ul>
+ <li>New AEAD API</li>
+ <li>SHA3</li>
+ <li>X25519 performance improvements</li>
+ <li>New IETF signature algorithms</li>
+ <li>PKCS#11</li>
+ <li>PRNG replacement</li>
+ <li>ASN.1 encoder/decoder replacement</li>
+ <li>STORE (certificate, crl, key storage API)</li>
+ <li>Replace CAPI with newer API engine</li>
+ </ul>
+ <p></p>
+
+ </div>
+ <footer>
+ You are here: <a href="/">Home</a>
+ : <a href="/policies">Policies</a>
+ : <a href="">Roadmap</a>.
+ <br><a href="/sitemap.txt">Sitemap</a>
+ </footer>
+ </article>
</div>
- <footer>
- You are here: <a href="/">Home</a>
- : <a href="/policies"> Policies</a>
- : <a href="">Roadmap</a>.
- <br><a href="/sitemap.txt">Sitemap</a>
- </footer>
- </article>
+ <!--#include virtual="sidebar.shtml" -->
+ </div>
</div>
- <!--#include virtual="sidebar.shtml" -->
- </div>
-</div>
-<!--#include virtual="/inc/footer.shtml" -->
-</body>
+ <!--#include virtual="/inc/footer.shtml" -->
+ </body>
</html>
projects / openssl-web.git / commitdiff