On 09/30/2015 01:29 PM, Kristian Fiskerstrand wrote: > On 09/30/2015 01:27 PM, hasufell wrote: >> On 09/30/2015 01:22 PM, Rich Freeman wrote: >>> On Wed, Sep 30, 2015 at 2:35 AM, Paweł Hajdan, Jr. >>> <phajdan...@gentoo.org> wrote: >>>> On 9/29/15 3:32 PM, Rich Freeman wrote: > > .. > >>> Perhaps the in-between solution would be for forking upstreams >>> to preserve the same symbol names as long as the APIs are >>> identical, and change them when they are not. I don't really see >>> that having any more impact on downstream consumers than silently >>> changing the APIs and it would probably get rid of the symbol >>> collision problem. >>> > >> Again: can you take that to libressl mailing list or start another >> thread? > > > The way I see it this is relevant to the discussion at hand. Before > implementing any system wide change to support LibreSSL, in order to > avoid future issues, a proper cost/benefit analysis and discussion is > in order. >
Since I am almost the only one working on it, I am not sure what you mean with that. If you have anything to add to the import discussion please do so. But this thread is not about the general course of LibreSSL, because we are not forking it. And I doubt that anyone here is going to do that, so I don't see how such discussion are relevant for us here. The relevant information that impacts us as distributors has already been added to this thread and the consequences are as follows: * virtual does not make sense * libressl USE flag is necessary * libressl has to conflict with openssl > Do we have an overview of what functionality and other pros (hereunder > security gains that is not fixed in OpenSSL) is gained by implementing > global LibreSSL support? > Yes, it is widely known: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities > Or is this just increasing our maintenance, and security tracking, etc > burdens without any strong benefits? > It increases maintenance burden in the same way that clang/libav/qt5 support increases maintenance burden.
