Well, in that case, didn't Fedora provide exactly what you say you want? Then the path forward for OpenSSH is sensible: port the code to the new API, and include Fedora-like library to interface with OpenSSL-1.0.x. So what's the problem? ;-) Regards, Uri Sent from my iPhone > On Oct 18, 2017, at 18:44, Damien Miller <djm@xxxxxxxxxxx> wrote: > >> On Wed, 18 Oct 2017, Blumenthal, Uri - 0553 - MITLL wrote: >> >> OpenSSL developers believed that there was a need for a significant >> change. A part of that change was a conscious choice to break (some >> of) the existing API. They considered that pain unavoidable. So far I >> happen to agree with their rationale and approach. Move from visible >> internal structures to accessor functions is a good thing, regardless >> of what you may think of it. And the new API *is* better, again like >> it or not. >> >> I understand the frustration with lack of a “migration library”, >> but how to you see a “shim” that allows code that relies on being >> able to directly access members of structures, run unmodified (just >> recompiled)? > > You've got this exactly backwards. We don't want a shim that allows > OpenSSL-1.1 to present a OpenSSL-1.0 API. We want a shim that allows > us to use the OpenSSL-1.1 API when using OpenSSL-1.0, so we don't have > to maintain a forest of #ifdefs.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
