[Cryptography] best practices considered bad term

[Viktor Dukhovni]

On Mon, Feb 02, 2015 at 09:55:22PM -0500, Jerry Leichter wrote:

> > Promote open source software: cheaper, less need to be buzzword-compliant,
> > more hope of being well implemented.
>
> You can actually say that with a straight face after the last 12 months?
> Heartbleed - and all the other bugs that the first serious look at OpenSSL
> then revealed?  Multiple serious bugs in bash?  Now GHOST?

I am currently involved in two starkly different OSS projects (also
others, but these two are extremes on the security track-record
spectrum), the first since 2001 and the second only recently.

In the first project:

    * The project founder is still its primary maintainer and takes
      pride of ownership in the project.

    * The project founder believes that security and code quality
      considerations trump features.  Contributions of code that
      addresses too narrow a problem, is poorly documented, or does
      not meet the coding standards are not accepted.  If a requested
      feature is sufficiently compelling, new code is written to
      implement it when time permits.

    * A lot of attention is paid to internal interfaces, which
      comprise the bulk of the code.  The code that implements
      features rides on top of carefully crafted libraries of
      general purpose code and is not polluted with platform-
      specific #ifdefs.  All internal interfaces are documented.

    * Preliminary documentation is, when appropriate, developed in
      advance of code for complex features.  Undocumented code is
      never released to the public.  All public interfaces are
      documented.

    * Snapshot releases are made often and expected to be production
      quality, what distinguishes  production releases is interface
      stability.

    * Official releases happen annually, and 4 official releases
      at a time are supported with bug-fix patches.  Patches for
      official releases do not add new features.  Only bug fixes
      go into official releases, and backwards compatibility is
      expected to be the rule across official releases, not just
      patches.

    * No features are developed to meet commercial contracts.

    * The project has never had a major security vulnerability,
      and the minor of minor ones is remarkably small.

In the second project:

    * The project founder has not been involved in the project
      for a long time.

    * For quite some time no project member has been the primary
      gatekeeper with the authority to reject poorly implemented
      or documented contributions.  This project is more democratic
      than the first.
      
    * The project has been feature driven, with contributions
      accepted based on their functionality first, and code
      quality considerations at best second.  Many features
      lack both internal and user documentation.  Commercial
      contracts work has driven the adoption of some features.

    * Releases have been infrequent, incompletely tested code
      accumulates over time, and stable releases introduce many
      features for the first time.  There was until recently poor
      separation of feature and bug-fix releases.

    * With nobody owning the overall project architecture, feature
      contributions have avoided refactoring internal code for the
      long-term health of the project.  Thus the internals have
      been somewhat neglected, with too much fragile low-level
      logic in the high-level feature code.

    * The project has a long and continuing history of security
      issues.

The above lists of contrasting project properties are not exhaustive.

So indeed, just being open-source does not ensure security, "many
eyes make all bugs shallow" has not worked out so well.  You need
the right eyes at the right time.

Open source just means that there are likely fewer secret "features"
that address the needs of a constituency other than the users.

Whether any given open-source project produces generally secure
code requires some scrutiny of the development practices of that
project.

-- 
	Viktor.