Hello Ingo, On Fri, Jun 23, 2017 at 1:26 AM, Ingo Schwarze <schwarze@xxxxxxx> wrote: > > Hi Emmanuel, > > Emmanuel Deloget wrote on Fri, Jun 23, 2017 at 12:26:47AM +0200: > > > * the openssl team has no real incentive to propose a shim ; > > If major application projects refuse to support their new release, > thus putting pressure on operating system distributions to not > completely switch to 1.1 either, that is not an incentive? Yes and no. The fact is that openssl is widely used by tons of projects. Even if a major project quits (and frankly, these days openssh is built around libressl, not openssl, so one car argue that openssh already leaved the boat) there is little incentive for the openssl to not continue in the same direction as other projects will follow anyway -- mostly because openssl is openssl, not because openssl is great (*). Why would the openssl team do that ? * it's time consuming, and their time is better spent on enhancing the security and features of the openssl libs * such a project is doomed. It would make the various downstream project move to the openssl 1.1 API, at which point the remaining distros will dump older versions, meaning that the shim will have a life duration of one, maybe two years. * yet during these two years, it might become a stable (as introduces by R.C. Martin : a stable software is one who as many clients and a limited set of dependencies), meaning that every little change in it might have tremendous effects on downstream projects. * its a rewrite of code they already wrote in the openssl library. * most of it is trivial * your specific downstream needs are different than another downstream's project need, so in order to satisfy everyone they'll have to build a complete library. Which is basically a rewrite of what they already did. So, to rephrase the question, why would they spend time to propose a difficult to maintain, not really needed, potentially large yet trivial, doomed library? > > Did I miss something? > > Maybe you are striving for the wrong goal. It is not a goal to > clobber something together and encourage OpenSSL to repeat such > recklessness in the future, and leave users out in the rain once > again. I fully understand that the API change was/is difficult. Yet, it's a proactive move (and not a bad one) to enhance downstream code and to limit the impact of further changes. You don't have to micromanage a quadrillion of structure members with confused semantics, meaning that there is less chance to misuse them. Furthermore you no longer have access to what are are really implementation details. > It is not a goal either to create a shim that is not > officially audited and thoroughly tested by the original authors > who know their original code best, to create a shim that creates > additional dangers for security. We are talking about security > software here, so this is not the place at all to lightly cobble > something together, in particular not in ways involving many lines > of additional code. And I fully get that as well. But since nobody will step in, one has to do the job. Luckily, many has jumped in (and I was ready to do that as well). Their shim code is, as expected, quite clear and it should be easy to spot anything suspicious or wrong (I suspect some BN_free() should be replaced with BN_clear_free() here and there, but for most part the BN_free() directly comes from the openssl code). The fact is that most added functions are setters and getters, so until you do things in the Widely Wrong Way, it should be ok :) I'm not talking about rewrite RSA_public_encrypt() :) > If a few important projects keep up resistance and refuse support > for 1.1 until OpenSSL rolls up their sleeves and fixes the mess > they have created, maybe they will eventually realize that they > started a job here, wandered off half-way, and failed to ever > properly finish it. Or another, less important project that did the jump will replace it because distros have limited patience w.r.t. softwares that do not want to evolve their API. Once the 1.0.2 support is out, distros will want to have 1.1 and softwares that do not want to move to that version will either be patched or replaced. Other implementations already exist, including dropbear, GNU lsh and probably others I don't know. Most of them are not as good as openssh and some of them are downright horrible to use (I'm looking at you, GNU lsh...) but the fact that some alternatives exists is what's important here. You also must take into account that some people want to have openssl 1.1 for wahetever reason (for example, TLS1.3 support in 1.1.1). For them, having to cope with multiple versions of the openssl library is not going to work well. Distro maintainers will also be rightly pissed off if only one important program does not want to take the jump. > So, such resistance has a chance to improve the situation for > everybody. And i can't think of many projects that are in as > widespread use as OpenSSH, and hence can be more valuable with > respect to such resistance. I'm not sure it's practical in the long term. Furthermore, one cannot really expect that the openssl team will deprecate the 1.1 API and move back to the Good Ol' Days of the 1.0.1 API. I'm not saying that resistance is futile but I'm not sure it will have the desired effect. > > Just my personal 2 cents, > yours, > Ingo Best regards, -- Emmanuel Deloget (*) that does not mean openssl is not great. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
