Hi Peter,
I believe that as a maintainer I stated same in a previous email, and
based on what I've read it seems very few maintainers/developers would
object to it if someone was willing to do the work to enable things to
co-exist. So a few points that I picked up during this discussion.
1. Nobody is AGAINST libressl per sé,
2. A number of people are AGAINTS the effort involved to make libressl
work for various packages.
Without the latter, libressl is dead since it can't install concurrently
with openssl. Which is why someone needs to make the effort. My
earlier suggestion for openssl-provider being an eclass I still think is
the best way to go, but this will require someone to write it.
With dubious benefits, I don't see a great many number of people jumping
at the opportunity, but I'm sure that if someone can manage the basis
for this, then sure. Again, this will mean for libraries that they will
need to have multi-implementation installations again, consider the case
where package A links both package B and open/libressl, and package B
also links open/libressl. In such a case package B would need to
install both variants if required. Similar to x86_32 vs x86_64, or the
various different python versions if you will. So we'd need
openssl-impl-multi and openssl-impl-single to accomodate these cases.
So how do you deal with package-b-libressl vs package-b-openssl in terms
of dependencies? Or must all libraries now that links one or both of
those also pull the same stunts (ie, install into
/usr/lib{,32,64}/{open,libre}ssl/) in order to not have conflicting linkage?
There are possibly cases where the consumer of package b can link
openssl where the library links libressl, but this would have name space
issues probably (you can refer to https://bugs.gentoo.org/649924 for the
kind of really hard to diagnose and fix bugs this results in).
Alternatively a virtual/libssl ... but these really only work where
there are COMPATIBLE APIs, which it's clear openssl and libressl is not.
There are other nuances involved too (ie, a -lssl without an explicitly
-L/usr/lib{,lib64}/sslimpl should fail, ditto for #includes without
specific -I) - it's going to be very involved (or at the very least the
DEFAULT implementation should be openssl). Lots of very finicky risks
that needs to be eliminated wih installing both openssl and libressl
concurrently.
Which means:
3. Very few people (if any) are going to be willing to put in the
effort to make the above happen.
4. Even if you can make that happen, it now means that as a maintainer,
I still need to at least compile-test every package release that I
maintain against both openssl and libressl - and either ban one
implementation or the other or patch it, again ... which is exactly what
developers/maintainers are complaining about.
So, if you are offering to put in the work required to make this happen,
sure, I'm sure the patches would be welcome, and I'm sure a number of
people would be willing to help you test and provide suggestions even.
If you want to drive libressl, the way musl and the like are driven,
filing bugs against packages that doesn't work well, and assisting with
patching, I'm fairly certain most developers won't mind, however, myself
included, would want to do as little as humanly possible around it. Of
course I'm fortunate in that my primary upstream is very supportive and
welcomes patches (of which I've submitted a number of over the last
decade), which means I don't have to carry patches in gentoo.git for the
most part.
Unless you, or someone else, is willing to put in that effort I'm afraid
I have to agree with most other devs: libressl is a novel idea and
concept, but it's dead. Someone (Michał?) mentioned it's more pain than
gain currently. And unless someone is willing to change that, I
seriously doubt anything you say is going to carry much weight. What
people are asking for is the motivation that you have whereby you feel
the gain is worth the (significant) pain. I too like the concept of
alternative choices, but each choice comes with a cost, and if the user
isn't paying that cost, a developer somewhere is. And having written my
fair share of code - the level of ask that you're asking for is much,
much larger than I think you realise.
mysql and mariadb started out very similar, and now there are two major
projects, and parts of it are installable separately (client libs). I
believe there was even work done to be able to install multiple server
versions concurrently (But since I don't have a requirement for this, I
haven't followed in detail). Needless to say, it's a LOT of work for
even the basics of what you're requesting.
To the best of my knowledge most Gentoo devs aren't getting paid to just
sit and do this work. If we get paid for doing work on Gentoo at all
(or rather, sanctioned to as part of our employment duties) we are
fortunate, I believe it's usually an employer that has vested interest
in Gentoo, and then we get paid to make that which our employers care
about work (In my case I'm fortunate in that I have some leeway to be
allowed to scratch a few extra itches here and there - but mostly
because those itches affect me and my fellow employee's productivity to
some extent or another).
I trust (hope) that this will give you a small amount of insight into
what you're asking. It's both a monumental technical challenge, as well
as a time/effort one even when there aren't significant technical
challenges. In short, the old adage about time and money wins out. If
you want someone else to spend the time, pay them, else put in your own
time. Every single person on this ML that I'm personally familiar with
puts in their own time because they want to - because it scratches an
itch they care about.
Kind Regards,
Jaco
On 2020/12/31 13:46, Peter Stuge wrote:
> Mike Gilbert wrote:
>>> It is important to me that you can choose dev-libs/libretls instead of
>>> having any libretls code on your systems, but I reject you forcing that
>>> choice of yours on everyone else.
>> I'm having trouble making sense of this sentence. Did you mean to
>> write "libressl" instead of "libretls" somewhere?
> Sorry, yes, that's right. "having any libressl code" is what I intended.
>
>
>> Anyway, it seems like the people maintaining libressl in Gentoo are
>> really not interested in keeping it going.
> I don't know? There wasn't much discussion about my suggestion to keep
> libressl code available in Gentoo in some ways causing no interference
> with same SONAMEs openssl.
>
> So again what I'm advocating for is creative ways to at the very least
> not have to remove it completely, which I think becomes easy, by
> redefining what a libressl ebuild installs for now. At the moment I'm
> thinking about these two:
>
> 1. no-brainer: libtls .so with libressl implementation
>
> 2. more novel: lib{crypto,ssl} static-libs in non-standard location
> with libressl.pc in default search path
>
>
>> A libtls wrapper around openssl seems much more manageable to me,
>> and that should probably be the default option for people.
> I disagree on both points.
>
> I'm still working on checking what 1. above requires. So far it looks like
> the answer will be "nothing"; an ebuild wouldn't need any patch at all,
> meaning zero overhead on bumps.
>
> And I for one certainly expect libressl libtls to be the default - that
> is the canonical upstream.
>
>
> Thanks
>
> //Peter
>
