Hi Ingo, On Wed, Oct 18, 2017 at 4:15 PM, Ingo Schwarze <schwarze@xxxxxxx> wrote: > Hi, > > jpbion@xxxxxxxxxx wrote on Wed, Oct 18, 2017 at 05:53:21AM -0700: > >> 4) As a first result, with no judgement on anyone, just looking at the >> data - the root cause of this issue seems to be the split of LibreSSL >> from OpenSSL > > No, you are totally misrepresenting the situation. The root cause > is the split of OpenSSL-1.1 from OpenSSL-1.0, and that OpenSSL > dumped the large and dangerous work of dealing with the large-scale > API change on each and every application project instead of providing > an official transition path that can be taken seriously. Important API change between major releases is something to be expected. Sometimes the changes are limited, sometimes thay aren't. The structure of the changes themselves is the reason why the openssl folks could not provide any migration path (the existance of this path would have negated the changes themselves). Anyway, this is done, and I'm not sure we have the power to go back in time to fix that (and I'm not even sure it's necessary to fix it). Anyway, I still agree with you: the problem is not the split, it's the API change. > LibreSSL has almost nothing to do with the problem. Even if LibreSSL > had never happened, the same problem would still exists. > > Oh, wait, LibreSSL has to do with it in one sense. It is available > as one possible way to *solve* the problem. Either temporarily or > for good, whichever you like. This is not a good idea IMHO. One want to be able to write security-related code easily, and the old OpenSSL API (and thus, the current LibreSSL interface) does not make that simple at all. As a result, we got many incorrect use of this very API in the past which led to security issues in many softwares (CVE-2009-0021). While some degree of API complexity is inherent to the role of the library, I'm pretty sure you can agree that the simpler it is, the better. Given the fact that the knowledge of the structures of LibreSSL is needed to correclty use the library, I hope you'll understand my point: using LibreSSL as it is today instead of porting to OpenSSL is not a good idea :) (Not to mention that more and more software implement compatibility with OpenSSL 1.1, so asking them to go the other way is not going to work well). >> OpenSSL and LibreSSL, given the fact neither seems to have a desire >> to maintain compatibility with the other (again, as far as I can see). > > That is an unfounded allegation. Of course LibreSSL has a desire > to eventually integrate the 1.1 API. Joel has said so long ago, > in public, that in principle, opaque structs are a good concept > [for example citation 1: Dec 30, 2016], and i have heard repeated > discussions inside the LibreSSL project on how to get there. It > is just a lot of work, it is made harder by the lack of a clear > migration path, and it is of limited usefulness as long as application > programs must still support the OpenSSL-1.0 API. That's what > prevented it from getting done so far. There is no easy migration path. More precisely, there is only one migration path, and it's not pretty. To allow applications to do the jump at their pace, you have to propose both interfaces and mark the old one as deprecated (and remove it in a subsequent release). I'd volonteer to do this but given the gigantism of the task, any help would be appreciated (not to mention that even if Joel agrees with the idea of having the 1.1 API in LibreSSL, that does not mean he would agree with my strategy). > Given that you got the facts wrong, your conclusions are misleading > as well. All this was explained already, so your mail sounds almost > trollish: It should already be well-known that the central design > goal of LibreSSL is to be a compatible drop-in replacement for > OpenSSL - at the time of the fork, that was OpenSSL-1.0. If, after > the fork, OpenSSL breaks its own API and leaves users in the rain, > blaming that on LibreSSL is quite dishonest. Even if the API break > is so severe that it takes LibreSSL substantially more than a year > to deal with it, even if LibreSSL hasn't yet solved the problem for > its own purposes. I agree with you on this one. The LibreSSL folks are not to be blamed for this situation. > The real problem is: How is OpenSSH supposed to support OpenSSL-1.0 > and OpenSSL-1.1 at the same time, given that the API break is so > severe that switching from one to the other requires a 3000+ line > diff? But at the same time, some ditributions are phasing out OpenSSL 1.0.2 and are integrating OpenSSL 1.1 while at the same time some supported LTS distributions still rely on older OpenSSL versions. So for a period of time you'll have to be compatible with both, whether you like it or not. The question is then: is it up to you to be compatible with both, or is it up to distributors to provide compatibilty? When more and more softwares propose their own shim it makes the later less and less understandable. > Yours, > Ingo BR, -- Emmanuel Deloget _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
