On Wed, 30 Sep 2015 15:22:40 +0200 hasufell wrote: > On 09/30/2015 02:10 PM, Kristian Fiskerstrand wrote: > > On 09/30/2015 01:51 PM, Rich Freeman wrote: > > > >> I think it was fair to pause to see if somebody could come up with > >> a better solution that allows co-existence, but absent that I > >> don't see any benefit from keeping libressl out of the tree. > >> We'll just experience all the downsides of the fork without the > >> upsides. > > > > This is what worries me as well, as it increase workload and > > complexity affecting multiple projects without any immediate and > > obvious gain. > > > > I'm not sure if you have followed the link I just posted: > https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities > > 0 vs 5 high severity vulnerabilities is a pretty obvious gain.
This is a poor argument, because user base of libressl is much smaller than of openssl, so probability of undiscovered issues is higher for libressl than for openssl. Yes, libressl is good at fixing openssl long-standing issues (e.g. dropping outdated code), but they may have their own critical vulnerabilities in some new functions, not present in openssl. Anyway diversity is very good for security: not everything will be affected by critical issues. The only thing bothers me that we will end up with two major packages demanding ssl implementation which can't be installed at the same time. While for now we tend to postpone solution of such problem, it is only matter of time when we'll face it. Perhaps static linking for one of the libraries will do the job, despite it sounds crasy. Still, we can go ahead and introduce some mechanism forcing static linking with libressl for consumer apps if user demands this. Best regards, Andrew Savchenko
pgpPXQXSTkmuw.pgp
Description: PGP signature
