[openssl-commits] [web] master update

Richard Levitte levitte at openssl.org
Tue Oct 25 16:15:26 UTC 2016


The branch master has been updated
       via  3e72a62c4a0bd69e5f2b4380dd070e5587e2c201 (commit)
       via  f490f29fd1fe31a0ffd360e818794e9c50a50db7 (commit)
      from  1bb9590bf583f21dc71b0adf83062f38e589644e (commit)


- Log -----------------------------------------------------------------
commit 3e72a62c4a0bd69e5f2b4380dd070e5587e2c201
Author: Richard Levitte <levitte at openssl.org>
Date:   Fri Oct 7 13:59:43 2016 +0200

    Install the new roadmap, saving away the old

commit f490f29fd1fe31a0ffd360e818794e9c50a50db7
Author: Richard Levitte <levitte at 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>
+


More information about the openssl-commits mailing list