policies/roadmap.html

   1 <!DOCTYPE html>
   2 <html lang="en">
   3 <!--#include virtual="/inc/head.inc" -->
   4
   5 <body>
   6 <!--#include virtual="/inc/banner.inc" -->
   7
   8 <div id="main">
   9   <div id="content">
  10     <div class="blog-index">
  11       <article>
  12         <header>
  13           <h2>Project Roadmap</h2>
  14           <h5>
  15             First issued 30th June 2014<br/>
  16             Last modified 8th August 2015
  17           </h5>
  18         </header>
  19
  20         <div class="entry-content">
  21           <p>
  22           This document is intended to outline the OpenSSL project
  23           roadmap. It is a living document and is expected to change
  24           over time. Objectives and dates should be considered
  25           aspirational.</p>
  26           <p>
  27           The OpenSSL project is increasingly perceived as slow-moving
  28           and insular. This roadmap will attempt to address this by
  29           setting out some objectives for improvement, along with
  30           defined timescales.</p>
  31
  32           <h3><a name='toc'>Table of Contents:</a></h3>
  33
  34           <ol>
  35             <li><a href="#current">Current Issues</a></li>
  36             <li><a href="#objectives">Objectives</a></li>
  37             <li><a href="#forthcoming">Forthcoming Features</a></li>
  38             <li><a href="#update">Roadmap Update History</a></li>
  39           </ol></p>
  40           <p>&nbsp;</p>
  41
  42
  43           <h3><a name="current">Current Issues</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
  44           <p>
  45           The OpenSSL project is currently experiencing a number of issues.
  46           These are:</p>
  47           <ol>
  48             <li><em>RT Backlog</em><br/>
  49             Over a period of some considerable time open tickets have
  50             been building up in RT (our bug tracking system) to the
  51             point that now there are a very significant number of
  52             them. A large proportion of these issues have been open
  53             for years. Some of these have in fact been dealt with and
  54             should be closed, but this has not been recorded in the
  55             system. Most however have not been looked at.
  56             </li>
  57             <li><em>Incomplete/incorrect documentation</em><br/>
  58             Documentation of OpenSSL is patchy at best. Some areas are
  59             well documented, while many others suffer from incomplete
  60             or incorrect documentation. There are also many areas
  61             which have no documentation at all.
  62             </li>
  63             <li><em>Library complexity</em><br/>
  64             The OpenSSL libraries and applications are complex,
  65             both from a maintainer's perspective and from a user's
  66             perspective. The public API contains many things which
  67             should probably be internal. The code has been ported
  68             to a large number of platforms, many of which are no
  69             longer relevant to us today, and this complicates the
  70             codebase. Some parts of the code have been in place for
  71             a very long time, and are in need of a refresh. It is
  72             further complicated by the support for FIPS.
  73             This complexity causes maintenance problems, and
  74             can also be the source of obscure and difficult to spot
  75             security vulnerabilities. It can also make users' lives
  76             much more difficult especially when combined with (2)
  77             above.
  78             The current memory management code has
  79             also been a source of problems and vulnerabilities.
  80             </li>
  81             <li><em>Inconsistent coding style</em><br/>
  82             There have been numerous developers working on the codebase
  83             over many years. There are many different styles used within
  84             the code, which is confusing and makes maintenance more
  85             difficult than it should be. Even if strictly consistent,
  86             the current code layout is unusual and idiosyncratic and
  87             unlike any other open source software.
  88             </li>
  89             <li><em>Lack of code review</em><br/>
  90             We don't have a code review system and we don't mandate code
  91             reviews.
  92             </li>
  93             <li><em>No clear release plan</em><br/>
  94             Historically OpenSSL has made new feature releases on
  95             an infrequent basis and no forward plan of releases has
  96             been published. It is difficult for users to plan for new
  97             releases, and understand when new features might become
  98             available, or when support will end for a release. In
  99             addition a large number of stable releases are maintained
 100             by the OpenSSL development team - diverting effort away
 101             from the most up to date versions.
 102             </li>
 103             <li><em>No clear platform strategy</em><br/>
 104             Historically OpenSSL has supported a very wide range of
 105             platforms. Typically platform support has been added through
 106             &quot;ifdef&quot; conditional compilation on a per platform
 107             basis. This approach has led to a number of problems:
 108             <ul>
 109               <li>
 110               The code has become very cluttered and is difficult to
 111               effectively maintain</li>
 112               <li>
 113               There is support still in the code for a number of legacy
 114               platforms which are unlikely to be widely deployed today -
 115               if the code even still works on those platforms</li>
 116               <li>
 117               In practice the development team do not have access to many of
 118               the platforms that the codebase supports and testing typically
 119               takes place on a very limited set (usually Linux, FreeBSD and
 120               Windows)</li>
 121             </ul>
 122             <del>
 123               <li>
 124               <em>No published security strategy</em><br/>
 125               We do not have a well-known and published approach for how we
 126               appropriately inform all interested parties of security
 127               advisories.</li>
 128             </del>
 129           </ol>
 130
 131           <p></p>
 132
 133           <h3><a name="objectives">Objectives</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
 134           <p>
 135           Each of the issues identified above can be translated into
 136           high level objectives. Some of these objectives can be
 137           achieved more easily and quickly than others.</p>
 138           <p>
 139           <em>An important principle is that the priority and focus of
 140             effort will be on achieving these objectives over and above
 141             the delivery of new features.</em></p>
 142
 143           <h4>RT Backlog</h4>
 144           <ol>
 145             <li>
 146             Manage all newly submitted RT tickets in a timely
 147             manner such as an initial response within four working
 148             days. (Timescale: Now)</li>
 149             <li>
 150             Reduce over time the existing RT backlog (Timescale:
 151             Ongoing). This may include the mass closure of very old
 152             tickets, such as those raised before the release of any
 153             currently supported version.
 154             <p><em>Update (8th September 2014)</em>:
 155             we have made a great deal of progress on the backlog.
 156             A <a href="ticket-activity.png">graph of ticket activity</a>
 157             is available, as is the <a href="buglist.txt">raw data</a>
 158             for every bug showing when it was open, and resolved. We
 159             will update these files periodically.</p></li>
 160           </ol>
 161
 162           <h4>Incomplete/incorrect documentation</h4>
 163            <ol>
 164              <li>
 165              Provide complete documentation for all of the public
 166              API (excluding deprecated APIs) (Timescale: Within one year).
 167              </li>
 168              <li>Some parts of the API have historically been public but were
 169              not intended for public use, such as low level cipher and digest
 170              APIs. These parts may not be documented, and if they are will be
 171              marked as deprecated (Timescale: within nine months).</li>
 172              <li>This may include introducing a new documentation system.</li>
 173            </ol>
 174
 175           <h4>Library complexity</h4>
 176           <ol>
 177             <li>
 178             Review and revise the public API with a view to reducing complexity
 179             (Timescale: Within one year)</li>
 180             <li>
 181             Document a platform strategy: see below (Timescale: Within three
 182             months)</li>
 183             <li>
 184             <del>Review and refactor the FIPS code to make it far less
 185             intrusive (Timescale: Within one year)</del>
 186             <br>Objective met (2015): The FIPS code has been removed from the
 187             master branch, and will be re-integrated more cleanly during
 188             a future validation.
 189             </li>
 190             <li>
 191             <del>Review and refactor the memory management code.
 192             (Timescale: Within six months)</del>
 193             <br>Objective met (2015): All use of dynamic memory allocation has
 194             been cleaned up and made consistent, and the internal memory
 195             pool has been removed.
 196             </li>
 197           </ol>
 198
 199           <h4>Inconsistent coding style</h4>
 200           <ol>
 201             <li>
 202             Define a clear coding standard for the project. This will cover not
 203             only code layout but also items such as how to handle platform
 204             dependencies, unit testing and optional code. (Timescale: Within
 205             three months).</li>
 206             <li>
 207             <del>Format the entire codebase according to the agreed standard.
 208             (Timescale: Within three months of coding standard being
 209             defined).</del>
 210             <br>Objective met (2015): All release branches were
 211             reformatted using a script included in the release.
 212             </li>
 213             <li>
 214             Refactor code to follow other parts of the style guide. (Timescale:
 215             Within one year)</li>
 216           </ol>
 217
 218           <h4>Code review</h4>
 219           <ol>
 220             <li>
 221             <del>
 222               Agree and implement a process such that all new commits
 223               should first be reviewed by a team member conversant
 224               with the relevant code and updated until the reviewer's
 225               issues are addressed. This is contingent on recruiting
 226               sufficient team members that reviewers are more-or-less
 227               always available. (Timescale: Within three months)
 228             </del>
 229             <br>Objective met (16th July 2014): All changes are first reviewed by
 230             another team member prior to being committed to the public openssl
 231             repository.
 232             </li>
 233             <li>
 234             <del>
 235               Agree on a code review system. (Timescale: Within six months)
 236             </del>
 237             <br>Objective met (2015): We use
 238             <a href="https://gitlab.com">GitLab</a>.
 239             </li>
 240           </ol>
 241
 242           <h4>Audit</h4>
 243           <p>
 244           Externally audit the current code base. (Timescale: Dependent on
 245           external body)</p>
 246           <p>Update (14th October 2014):
 247           Auditors selected and funded; schedule being worked on.</p>
 248
 249           <h4>Static/Dynamic Analysis</h4>
 250           <p>
 251           Regularly audit the code using appropriate analysis tools.
 252           (Timescale: Within six months)
 253           </p>
 254
 255           <h4>Release Strategy</h4>
 256           <del>
 257           <p>
 258           We intend to develop a release strategy which will set out our plans
 259           for how frequently we plan to release, and when. It will also cover
 260           how long releases will be supported for, and when their EOL (End Of
 261           Life) will be. (Timescale: Within three months)</p>
 262           <p>
 263           There are a number of objectives that we would be seeking to address
 264           within the release strategy. Some of these objectives compete with
 265           each other, and so from necessity there will have to be compromises.
 266           The objectives are:
 267           <ol>
 268             <li>
 269             We need security fix releases with very low chance of breaking
 270             anything. This is largely met by prohibiting new features in stable
 271             branches (i.e. letter releases).</li>
 272             <li>
 273             If something is broken in a release a fixed version should be made
 274             available shortly afterwards (i.e. more letter releases more
 275             often)</li>
 276             <li>
 277             We need a way to get new binary compatible features into OpenSSL
 278             relatively quickly.</li>
 279             <li>
 280             We don't want to have to maintain too many branches. This is likely
 281             to include a timescale for the EOL of version 0.9.8</li>
 282             <li>
 283             We need a way to refactor code and make necessary binary
 284             incompatible changes, deprecating APIs etc.</li>
 285           </ol>
 286           </del>
 287           Objective met (2015): We have announced a
 288           <a href="releasestrat.html">release strategy</a>
 289           which includes end-of-life and long-term support definitions.
 290           Also, our
 291           <a href="secpolicy.html">security policy</a> has relevant
 292           information.
 293           </p>
 294
 295           <h4>Platform Strategy</h4>
 296           <p>
 297           Moving forward OpenSSL will adopt the following policy:</p>
 298           <ul>
 299             <li>
 300             There will be a defined set of primary platforms. The primary
 301             platforms will be Linux and FreeBSD. A primary platform is one where
 302             most development occurs.</li>
 303             <li>
 304             In addition there will be a list of secondary platforms which are
 305             supported by the development team.</li>
 306             <li>
 307             Platform specific code will be moved out of the main codebase
 308             (removing overuse of &quot;ifdef&quot;).</li>
 309             <li>
 310             Legacy platforms that are unlikely to have wide deployment will be
 311             removed from the code.</li>
 312             <li>
 313             Non-supported platforms requiring regular maintenance activities
 314             will eventually be removed from the code after first seeking
 315             community owners to support the platforms in platform specific
 316             repositories.</li>
 317           </ul>
 318           <p>
 319           Necessary criteria for a platform to be included in the secondary
 320           platform list includes:</p>
 321           <ul>
 322             <li>
 323             Currency, i.e. a platform is widely deployed and in current use</li>
 324             <li>
 325             Vendor support</li>
 326             <li>
 327             Available to the dev team, i.e. the dev team have access to a
 328             suitable environment in which to test builds and deal with tickets
 329             and issues</li>
 330             <li>
 331             Dev team ownership, i.e. at least one person on the team is willing
 332             to take some responsibility for a platform.</li>
 333           </ul>
 334           <p>
 335           In addition the secondary list will be as small as possible so as not
 336           to spread the development team too thinly.</p>
 337           <p>
 338           The secondary platforms are still to be defined but will be based on
 339           the above criteria. For each primary/secondary platform, we should
 340           have, at least, a continuous integration box and a dev machine we can
 341           access for test/debug. We will seek support from the platform vendors
 342           or the community to provide access to these platforms. The secondary
 343           platform list will change over time, but an initial list will be
 344           produced within three months.</p>
 345           <p>
 346           The Platform Strategy will be phased in over a period of time based
 347           on how quickly we can refactor the code.</p>
 348
 349           <h4>Security Strategy</h4>
 350           <p>
 351           <del>
 352             We will be documenting a security strategy which will define our
 353             policy on how we make security fixes, and what (if any)
 354             pre-notification of forthcoming security releases will be provided
 355             (and to whom) (Timescale: Within two months)
 356           </del>
 357           <br>Objective met (7th September 2014): The OpenSSL security policy
 358           is available <a href="secpolicy.html">here</a>.
 359           </p>
 360
 361           <h3><a name="forthcoming">Forthcoming Features</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
 362           <p>The primary focus of effort will be on achieving the
 363           objectives detailed above, however we are evaluating the following
 364           new features.</p>
 365
 366           <ul>
 367             <li>IPv6 support</li>
 368             <li>AEAD updates (API review, Poly/ChaCha support, /dev/crypto
 369             operations coalescing)</li>
 370             <li>TLS 1.3.</li>
 371             <li>Certificate Transparency support</li>
 372             <li>Support for new ciphersuites e.g., CCM</li>
 373             <li>Extended SSL_CONF support</li>
 374             <li>DANE support</li>
 375             <li>Security levels (currently experimental in master)</li>
 376             <li>OCB</li>
 377             <li>FIPS code review and refactor</li>
 378             <li>Support for emerging platforms, e.g. ARMv8, POWER8</li>
 379             <li>Built-in multi-threaded support for two major threading
 380             "flavours," POSIX threads and Win32</li>
 381           </ul>
 382           <p></p>
 383
 384           <h3><a name="update">Roadmap Update History</a> <a href="#toc"><img src="/img/up.gif"/></a></h3>
 385           <p>
 386           The following changes have been made since the roadmap was first
 387           issued 30-June-2014.
 388           </p>
 389           <ul>
 390             <li>8-August-2015.
 391             Many updates, for what happened in 2015.</li>
 392             <li>14-October-2014.
 393             Updated audit; added TLS 1.3 and Certificate
 394             Transparency to features.</li>
 395             <li>8-September-2014.
 396             Updated status on the RT backlog objective.</li>
 397             <li>7-September-2014.
 398             Updated security policy section.</li>
 399             <li>16-July-2014.
 400             Updated code review section.</li>
 401             <li>1-July-2014.
 402             Noted RT is our bug tracking system.</li>
 403           </ul>
 404         </div>
 405         <footer>
 406           You are here: <a href="/">Home</a>
 407           : <a href="/policies"> Policies</a>
 408           : <a href="">Roadmap</a>.
 409           <br><a href="/sitemap.txt">Sitemap</a>
 410         </footer>
 411       </article>
 412     </div>
 413     <!--#include virtual="sidebar.inc" -->
 414   </div>
 415 </div>
 416
 417 <!--#include virtual="/inc/footer.inc" -->
 418 </body>
 419
 420 </html>
 421