On Mon, 2020-12-28 at 23:18 +0000, Peter Stuge wrote: > Michał Górny wrote: > > > A. It is a distinct implementation with probably /quite some/ > > > stable > > > compatibility, meaning that it will work perfectly fine as an > > > alternative in many cases. > > > > Except that it doesn't, as has been proven numerous times. > > I'm sure that there are numerous cases where libressl doesn't work, > but that's no reason to dismiss cases where it *does*.
Are you asking people to put an effort into maintaining something that can't be practically installed? 'I don't use a single Qt application (yet!), so I demand you support LibreSSL for me!' A side effect of this approach is that users will be tricked into using LibreSSL, only to discover that they eventually have to transition their systems back. We have been there with LibAV. However, unlike LibAV, transition between SSL providers is non-trivial. > Did anyone gather actual numbers? $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l 61 That's just the tip of the iceberg. Nobody's going to be able to even guess how many upstream have accepted *bad* patches. How many packages are forcing obsolete algorithms because someone added '!libressl' conditions because LibreSSL keeps pretending to be a newer OpenSSL version without actually implementing its API. > > > B. It brings its own TLS API, a unique feature which by itself > > > warrants the package. > > > > ...which by itself has no future > > That's arrogant and silly coming from anywhere but upstream. > > You can argue that you will never use the API in your TLS programs, > but even then that says really nothing about the API provider itself. That's my opinion and I have a right to have it without being insulted. I don't dispute whether it's good. I dispute whether tightly binding it to a problematic LibreSSL is a good idea. Sure, this means that some people will be forced to use LibreSSL because of libtls. But in practice, this means that any upstream starting to use libtls does a huge disservice to their users by preventing them from using their preferred SSL provider. So in the end, you either don't use libtls or your users are in pain. Actually, I see that someone has apparently forked libtls into libretls (the irony!) that works against OpenSSL [1]. [1] https://git.causal.agency/libretls/about/ -- Best regards, Michał Górny
