[openssl-users] OpenSSL Release Strategy and Blog

[Jakob Bohm]

On 28/12/2014 12:26, Kurt Roeckx wrote:
> 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.)
Yep, I presume the distribution packagers used different compile
options for the 1.0.x installed in /usr/lib, than I had used for the
1.0.1 installed in /usr/local/lib.
>>    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.
Yes, that's exactly the one.
>
>>   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.
I agree, that is why I had a locally compiled 1.0.1 on that particular
system.
>
>>    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.
Thing is that the AES_, DES_ etc. functions have long been a key part
ofSSLeay/OpenSSL.  Notably, the DES library had previously been
distributedseparately, and the large integer library is a key
componentfor people implementing new new crypto algorithms and
methodsnot yet (or ever) in OpenSSL.

And unlike higher level mechanisms, they tend not to bloat statically
linkedapplications with lots unused code.(Though the use of EVP
insidethe RNG forced me to do some patching to avoid pulling in the
EVP RSA code).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20150107/6259da20/attachment.html>