Just before we dive further into this thread, I'd like to clarify that the reason for this debate is really to help establish a strategy forward, not a way to push for a change next week disregarding packagers.
I want to be sure I understand the limiting factors here and there, so the change CAN happen (it is going to sooner or later), but in a way that does not hurt users and that packagers can cope with. On Thu, Dec 24, 2015 at 04:34:34AM +0600, Denis Fateyev wrote: > On Wed, Dec 23, 2015 at 9:16 PM, Gilles Chehade <[email protected]> wrote: > > > > > What I'm wondering is if there's any reason that would prevent RHEL, for > > example, to package LibreSSL in the same way that libasr was packaged so > > that OpenSMTPD could specifically depend on it. > > > > The system would keep its default SSL library. > > > > Well, it's only my opinion so I can miss some points here. Briefly, why > libressl doesn't come here: > > 1) The first problem is that unlike third-party "libasr" library these > chaps "libressl" and "openssl" are way too close, and it creates > temptations and mistakes. Due to human nature, new options provide more > possibility to slip up. Being provided with two similar options, some > developers won't be considering open-(libre-)ssl corner cases you've > mentioned for example, some will mix these two solutions up, etc. All > users, in general, hate the idea that due to these changes something can be > randomly broken. > This loses me, or I'm missing a keypoint: To me, the fact that two libraries are close is not really a technical issue that can't be overcome. Two different versions of OpenSSL could be installed in different places, and this holds true for LibreSSL no ? This seems more like a packaging issue because LibreSSL could very well stay in /usr/lib/libressl, or whatever is the convention on the target distro, so it lives side by side and doesn't affect other applications. Say tomorrow I started OpenWhateverD, it relied solely on LibreSSL's libtls, and you REALLY had an interest in it, how would you work that out ? > It can be solved, but I don't know anybody from the Fedora community who'd > be willing to: > > - reconcile issues on similar soname provides, naming, versioning etc. > with Fedora and RedHat technical board in order to avoid all possible > intersections with this critical system component; > - support "libressl" globally similar to "openssl" case, fixing security > CVEs always getting in touch (being such package maintainer is not a > one-time task); > - consult RH/Fedora developers promptly fixing their libressl-specific > issues - and all this responsibility on a voluntary basis. > I can understand this but then it's a distribution specific issue and it isn't limited by a technical problem. This can be taken into account when making the move so that the package maintainer can sort things out but I don't think that it should be a justification to prevent move and limit our progress. If no one in the Fedora community would be willing to work out a solution then it would be an indicator that we're holding back for a community that does not really care so much about having the project or not. If that was the case then it would question why we're holding back really :-) If there is a technical problem, then it is different because we're willing to help work things out. > 2) From the enterprise point of view, there is no sense to support it as an > openssl replacement now. > It's not FIPS-certified so they cannot use it in enterprise solutions where > openssl currently in charge. For simplicity, better not to have an unusable > alternative (in context of this situation, of course). They won't sponsor > its maintenance so it's up to the community. Surely this can change if > business sees a use case for this specific library's clone but there is no > any so far. > Unlike the above, this is irrelevant to me, I don't think any opensource project should be driven by what makes sense to a particular company. We were sponsored full-time for over a year by my employer, and then the direction we were taking no longer made sense for them. We could have adapted our direction to keep the sponsoring, but it would have been a bad thing for the project, so we part ways (on sponsorship). Clearly, I can take anything into account but not this :-) > The arguments on switching to libressl are quite logical, but I don't see a > straight way how to do it in RHEL and Fedora considering all above. > Ok, so then the question is: There's no straight way, so how do we plan for a curvy way ? :-) > By the way, how about GnuTLS support? > We have no interest for that. The code was written using the OpenSSL API because we were used to it and clearly the push for a move to LibreSSL is primarily done because it is a way out of the OpenSSL API and towards the libtls API. Replacing an API that we don't like by another that doesn't bring any clear improvements with regard to being confident about the code will not really be a move forward. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
