[openssl-users] OpenSSL Release Strategy and Blog

[Jakob Bohm]

On 24-12-2014 00:49, Matt Caswell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement
> contained a link to the recently published OpenSSL Release Strategy that
> is available here:
> https://www.openssl.org/about/releasestrat.html
>
> I have put up a blog post on the thinking behind this strategy on the
> newly created OpenSSL Blog that you may (or may not!) find interesting.
> It can be found here:
> https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/

I am afraid that this is a somewhat rush decision, with insufficient
consideration for the impact on others:

1. Because this was announced during the Xmas/New year holidays, many
  parties will not see this until the beginning of 2015.

2. The decision that 1.0.0 and 1.0.1 should both be classed as a STS
  releases seems new, and is unlikely to have been anticipated by many
  "users".  Many will have naturally assumed that 1.0.0 would last as
  long as 0.9.8 lasted.

   So announcing the imminent death of 1.0.0 at the same time as 0.9.8
  is going to be a nasty surprise to anyone who already froze their
  projects on the 1.0.0 series rather than the new and more unstable
  1.0.1 series.

3. The 1.0.x binary compatibility promise seems to not have been
  completely kept.  As recently as just this December, As a practical
  example: I had an OS upgrade partially fail due to the presence of
  a self-compiled up to date 1.0.1* library that conflicted with an
  OS supplied 1.0.x library that was frozen earlier while relying on
  your promise.

   Also the 1.0.1 changelog includes at least one change of binary
  flag values to get a different compatibility behavior than
  previous 1.0.1 releases, thus there is not even binary
  compatibility within 1.0.1 .

4. LTS release periods have an absolute need to overlap, such that
  at any given date, there is at least one active LTS release known
  not to end within the next many years, otherwise the whole concept
  is useless.  On any given day of the year (except, perhaps, holidays),
  a project somewhere is going to look at available tool and library
  releases and decide which one is most likely to be supportable for
  the next N years, then irreversibly freeze on that version.  So if
  OpenSSL has no active long term release with at least 3 to 5 years
  left, then OpenSSL is not viable or projects will have to incur the
  cost of having security-novices backport security fixes manually
  to an unsupported version for the remainder of the needed N years.

   Accordingly the policy should be that there will always be at least
  one LTS release which is at least one year old and has at least 5
  years left before security support ends.  For comparison, Microsoft
  usually promises security fixes for 10 years after release, non-
  critical fixes for only 5, and people still complain loudly when the
  10 year period is up for e.g. NT 4.0 and XP.

   Since you have already announced the upcoming end of 0.9.8, you
  must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1)
  as the new LTS release, and you need to deal with the fact that
  since the 0.9.8 end-of-life announcement, you have been unclear
  which of the two existing 1.0.x releases would be LTS-security,
  causing some projects (not mine, fortunately) to irreversibly
  pick a different one than you did.

5. Since its original release as part of SSLeay, libcrypt has become
  the dominant BSD-licensed library of raw crypto primitives for all
  sorts of uses, such as (but not at all limited to), openssh, the
  SRP reference implementation, the NTP cryptographic support etc.

   Limiting the capabilities, transparency or other aspects at this
  point in time is way, way too late.  It is as futile as when the
  ANSI/ISO C committee tried to remove the UNIX-like file handle APIs
  (io.h) in favor of the FILE* API (stdio.h) at a time when the C
  language was about the current age of OpenSSL.

   The best you can do is to split libcrypt into two or tree well
  defined layers, that can be mixed in applications but do not break
  their layering internally.  These could be: rawalgs (non-opaque
  software primitives, bignums etc.  with CPU acceleration but
  nothing more fancy), EVP-api (opaque structures with hidden heap
  allocations, engine and FIPS support, but no forced loading of
  unused algorithms, except for the all-or-nothing-ness of fips and
  other engine blobs), and NID-API (algorithms referable by numeric
  IDs, large bundles of algorithms loaded by master-init functions,
  automatic X.509 checking/use based on embedded algorithm OIDs etc.).

   Ideally, the rawalgs level should never make its own heap
  allocations, except in compatibility functions for older APIs that
  did, and should be usable in deeply embedded systems, such as OS
  loaders and door locks.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded