[openssl-users] OpenSSL Release Strategy and Blog

[Kurt Roeckx]

On Sun, Dec 28, 2014 at 01:31:38AM +0100, Jakob Bohm wrote:
> 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.

Can you give more details about this?  Please note the binary
compatibility will only work if you used the same options to build
the library.  (This is one of the reasons to make more structures
opaque.)

>   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 .

I assume you're talking about SSL_OP_NO_TLSv1_1?  It's unfortunate
that SSL_OP_ALL already contained that in 1.0.0 while 1.0.0
doesn't even know anything about TLS 1.1.  But that only affects
people who compiled with 1.0.1 or 1.0.1a headers.

>  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.

I think people should stop using both 0.9.8 and 1.0.0 as soon as
possible since they do not support TLS 1.2.  You really want to use
TLS 1.2.

>   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)

I don't think we intend to remove functions like AES_* yet but
might deprecate them in favour APIs that exist for a very long
time.  Please note that for instance using the AES functions you
do not have AESNI acceleration but by using the EVP interfance you
do.


Kurt