On 2017-06-24, Douglas E Engert <deengert@xxxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
