On December 29, 2020 4:39:06 AM EST, "Michał Górny" <mgo...@gentoo.org> wrote:
>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!'
>

I don't see Peter demanding anything here. He has an opinion as a user and he 
has offered it. Just as others have offered theirs.

>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.
>

No one is tricking anyone into using LibreSSL.

>> 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.
>

That's quite an assumption to assume all of these patches are "bad."

>> > > 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.
>

Yes, you do. Just as others have a right to theirs without being spoken to as 
you have done so here.

It is clear you have a problem with the LibreSSL implementation, but portraying 
that as a user being ignorant, demanding, or anythimg else is uncalled for to 
get your point across. 

Quit saying people are insulting you when you have clearly done so in the very 
same email response. 

>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/

Anyway, +1 for LibreSSL removal.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply via email to