The branch master has been updated
via 3e72a62c4a0bd69e5f2b4380dd070e5587e2c201 (commit)
via f490f29fd1fe31a0ffd360e818794e9c50a50db7 (commit)
from 1bb9590bf583f21dc71b0adf83062f38e589644e (commit)
- Log -----------------------------------------------------------------
commit 3e72a62c4a0bd69e5f2b4380dd070e5587e2c201
Author: Richard Levitte <levi...@openssl.org>
Date: Fri Oct 7 13:59:43 2016 +0200
Install the new roadmap, saving away the old
commit f490f29fd1fe31a0ffd360e818794e9c50a50db7
Author: Richard Levitte <levi...@openssl.org>
Date: Fri Oct 7 07:25:03 2016 +0200
New roadmap and platform policy
-----------------------------------------------------------------------
Summary of changes:
policies/roadmap_2015-2016.html | 421 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 421 insertions(+)
create mode 100644 policies/roadmap_2015-2016.html
diff --git a/policies/roadmap_2015-2016.html b/policies/roadmap_2015-2016.html
new file mode 100644
index 0000000..133584a
--- /dev/null
+++ b/policies/roadmap_2015-2016.html
@@ -0,0 +1,421 @@
+<!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>
+ Manage all newly submitted RT tickets in a timely
+ manner such as an initial response within four working
+ days. (Timescale: Now)</li>
+ <li>
+ 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><em>Update (8th September 2014)</em>:
+ 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.</p></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>
+ </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>
+ <!--#include virtual="sidebar.shtml" -->
+ </div>
+</div>
+
+<!--#include virtual="/inc/footer.shtml" -->
+</body>
+
+</html>
+
_____
openssl-commits mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits
