Hello everybody, I saw that another discussion about OpenSSL 1.1 support started on this list, and I'd like to know what is the current status about this. >From what I understand, at least one patch set already exists: a github PR [1] from , Kurt Roeckx announced on the list in september 2016 [2] and which also exist as a fedora patch [3] (I haven't checked the details, and maybe the PR and the fedora patch are a bit different). The problems that were signaled during the september/november 2016 discussion and the recent one are: * it breaks LibreSSL builds * the changes are only relevant to openssh-portable * it involves maintaining a shim which might be buggy * openssl 1.0.2 is LTS and support is longer than for openssl 1.1.0 * a few major distributions (including some older RHEL versions) are stuck with even older releases * changes in openssl 1.1 are not a sufficient motive to do the job anyway * this is quite a large change (the fedora patch is more than 3000 lines long) Forces that would drive the changes are: * fedora already has it. * latest debian unstable are to be based upon OpenSSL 1.1. * eventually 1.0.2 will fade out so being ready to support openssl 1.1 (and later versions) is likely to pay out at some time * a late change is going to be even larger than the current fedora patch (hello, technical debt). * new features in future openssl release I probably missed a few thing here and there. Now, I recently completed a similar change for OpenVPN [4] - as the currently proposed patch, it involves a shim, although this one is made of static inlines in a header file. It allowed the OpenVPN team to add an openssl 1.1 build target on travis and subsequent changes will be tested against this build target (so new openssl 1.0.x artefact cannot be introduced again in the code) as well as against already existing targets (meaning that introducing the use of another openssl 1.1 function into the code will force a change in the shim). So it basically takes care of everything. Report has been made that it does not break the LibreSSL build. For further ease of management, the shim itself is broken in multiple parts. The configure script checks for the presence of each OpenSSL 1.1 needed function, and one #define is generated for each function. The code does not really care if the function comes from 1.1.0 or 1.0.2. I was in the process of doing something similar for openssh-portable when I found out about Kurt's patch. His work is more advanced than mine, so I'm wondering if I should continue (I can always rework his patch to adapt it to the process I outline above ; furthermore I think there might be other issues than the double free [5] in the code, but I have to double or triple check my intuition here, as I kind of always get wrong when I state something like this). My opinion is: * the openssl team has no real incentive to propose a shim ; moreover such an "official" shim is not guaranteed to be used by downstream. * an independant openssl shim project is likely to fail -- it stills require a large amount of work for downstream projects as they still need to adapt their code to the new openssl API. * so downstream projects are kind of forced to implement their own shim anyway . I fully understand that it's not an ideal solution. I believe it's possible to build a shim with the following features: * compatible with openssl 1.0 to 1.1 and current versions of libressl (e.g. the one in OpenVPN has been tested with openssl 0.9.8 ; when I started development RHEL 4 was not yet eol'ed) * easy to change when an openssl version is deprecated * small enough to avoid security bugs in the shim itself The latest is especially important, and my intuition is that most of the shim (if not all) is made of functions whose goal is to either get or set openssl structure members. This code is quite straigtforward and should not pose any threat. Compatibility with libressl is granted as long as the shim implement missing (openssl 1.0.2+) functions using the openssl 1.0.1 API. This should be guaranteed until the eol of openssl 1.0.2. A problem may arise if we need to implement openssl 1.2+ API using the openssl 1.1 API (yet we still have some time before we'll face this situation). Ease of change is always relative, but the goal is to limit the number of changes when one must add or remove a function from the shim. Did I miss something? Is the community interested in having support for openssl 1.1? What should an ideal openssl 1.1 support look like? Do you have any question? Comment? How many question mark can I add in the paragraph? Best regards, -- Emmanuel Deloget [1] https://github.com/openssh/openssh-portable/pull/48 [2] http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html [3] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch [4] https://github.com/OpenVPN/openvpn [5] http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-June/036083.html _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
