OpenSSL 1.1 support status : what next?

[Douglas E Engert]

On 6/25/2017 4:47 AM, Stuart Henderson wrote:
> On 2017-06-24, Douglas E Engert <deengert at gmail.com> wrote:
>> My reading of the discussion was to keep the older API to avoid changing the
>> OpenSSH code so a shim would be to support an "old API in a newer environment(OpenSSL-1.1)".
> 
> Exactly the other way round.

Upon further review, I stand corrected. OpenSC's approach [1] is similar
to the examples in this thread.

> 
> Since it seems 1.0.x is going to be around for some years yet until
> RHEL7 is end-of-life, there's clearly a need for downstream projects
> to work with multiple OpenSSL versions.
> 
> Many projects have been handling the conversion with #ifdef'd
> compatibility code, which is hard to read and hard to test. (As a
> packager for an OS using LibreSSL this is very obvious as these almost
> all check OPENSSL_VERSION_NUMBER and need changes for LibreSSL).
>

> It's obvious why people have been taking this approach - it has long
> been the usual approach to deal with new functions being introduced
> in the OpenSSL API. It's not quite so messy when using it to disable
> certain features not yet supported, but using it for whole parallel
> codepaths gets a lot more confusing (and diffs get rather hard to
> review).
> 
> Additionally it seems like some of this code (especially for smaller
> projects) has come from users not especially familiar with either the
> downstream code *or* OpenSSL, whose main motivation is to unbreak build
> for OS that are using 1.1, and are less interested in 1.0.x.
> 
>> What we did was to convert OpenSC to the OpenSSL-1.1 API the write the shim
>> for "new API in an older environment".
>>
>> Looking at your openssl_compat.h it looks like you have done something similar.
>> With OpenSC we only added the routines and defines we needed in OpenSC.

Yes, supports multiple OpenSSL and LibreSSL.

> 
> Using shims like this and writing to the new API seems exactly the right
> approach, and is similar to what OpenSSH-portable has done successfully
> for years. But isn't it silly that each project wanting to support both
> old+new OpenSSL has to maintain their own shim?

Yes, but to OpenSSL's credit, they have been moving in this direction,
in previous releases, with adding macros or routines to do move away from
direct access to what are now hidden structures. But they have now forced
the use of these new routines and additional hidden structures in 1.1.

> 
> This would all be a lot simpler for downstream projects if there was a
> single trusted source for such a shim, coming from people familiar with
> the OpenSSL code. Then those downstream projects (who know their *own*
> code well) can treat it as a simple API change and not have to worry
> about compatibility.
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 


[1] https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h
-- 

  Douglas E. Engert  <DEEngert at gmail.com>