OpenSSL 1.1 support status : what next?

[Stuart Henderson]

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.

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.

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?

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.