Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
>
> Installing both openssl and libressl .a files in different directories
> seems both useful and straightforward. I don't object to openssl being
> favored for /usr/lib here, libressl gets a directory of its own, but
> libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically.
> Obviously this will only be useful for packages wanting to statically link
> with libressl lib{crypto,ssl}
There is an ongoing effort to remove static libraries from packages.
but I think that's far better than removing
> libressl.
>
No, it's not better, it's more work for the security team.
>
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
Hi Jaco,
Jaco Kroon wrote:
> So a few points that I picked up during this discussion.
>
> 1. Nobody is AGAINST libressl per sé,
Michał gives me a distinctly different impression.
> 2. A number of people are AGAINTS the effort involved to make
> libressl work for various packages.
Yes, and I've written that I am as well.
> Without the latter, libressl is dead
On this I disagree.
> since it can't install concurrently with openssl.
Again, that need not be the case, and I'm looking into what's
possible with little to no effort:
Installing both openssl and libressl lib{crypto,ssl}.{a,so} in the same
directory is not possible since file names are the same.
Installing both openssl and libressl .so:s in different directories is
not extremely useful (but perhaps still worthwhile) since one dep for a
given package may pull in openssl and another dep may pull in libressl -
even if path stuff is resolved neatly this doesn't work at load time.
This is only useful for the case of packages explicity needing
libressl, e.g. because of (ab?)use of internals, which have no deps
which can not also use libressl without constant overhead in Gentoo.
Maybe openntpd actually falls in this category.
Installing both openssl and libressl .a files in different directories
seems both useful and straightforward. I don't object to openssl being
favored for /usr/lib here, libressl gets a directory of its own, but
libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically.
Obviously this will only be useful for packages wanting to statically link
with libressl lib{crypto,ssl} but I think that's far better than removing
libressl.
Installing libressl libtls.{a,so} (built using libressl lib{crypto,ssl}
code of course) in /usr/lib also seems both useful and straightforward.
I expect this to be the default provider for (a new) virtual/libtls.
The latter two cause no conflicts and have no running overhead cost.
> Again, this will mean for libraries that they will need to have
> multi-implementation installations again
This is interesting; I suppose that this is supported very well by Nyx,
and I think it would be a great addition to Gentoo, but in any case it
will not be trivial, and I wouldn't want to make it a requirement for
having /some/ libressl code on Gentoo systems.
Hence I propose to redefine the meaning of "support for LibreSSL" to
what works well without causing lots of overhead. Again: It's not
reasonable for Gentoo to patch the world, but we should model it as
accurately as possible.
> So how do you deal with package-b-libressl vs package-b-openssl in terms
> of dependencies?
I've mentioned a couple of ideas in this thread but they're all
non-trivial and I propose to not solve this problem for now and
settle for less than a full install until someone finds a good,
manageable solution.
> Lots of very finicky risks that needs to be eliminated wih installing
> both openssl and libressl concurrently.
So again, the point is to redefine what "libressl installed" means
such that the problems are avoided, accepting that libressl
lib{crypto,ssl}.so may not get installed, at least for now,
until there's a good solution - which is really orthogonal to
libressl. Quite probably the same solution could then apply to the
other packages in similar situations (ffmpeg/libav, imagemagic, etc.).
> 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.
I hope it's becoming clear that what I am saying is about /how/ to
change that, and that should carry weight. Consider it brainstorming
solutions if you will.
> having written my fair share of code -
Same.
> the level of ask that you're asking for is much, much larger than I
> think you realise.
I hope what I am asking for is becoming clear. I wrote fairly early
in the thread that it's something other than the status quo.
> mysql and mariadb started out very similar, and now there are two major
> projects, and parts of it are installable separately (client libs).
Off-topic, but I'm really happy about MariaDB! I remember helping with
a MariaDB developer meeting in the early days and I was very excited
that most long-time developers decided to join Monty on MariaDB. Ever
since, MySQL is irrelevant to me. But I do appreciate that people who
are stuck with some Oracle support contract can still use it in Gentoo.
> I trust (hope) that this will give you a small amount of insight into
> what you're asking.
I thought it was clear for a good number of mails that I'm /not/ asking
to continue ensuring that openssl and libressl are interchangeable in
Gentoo;
I'm asking to ensure that libressl stays available /in some capacity/ even
if that can only be as a special case, and it looks like that would
require only very little upfront effort and zero recurring effort.
Thanks a lot for your thoughtful response! I hope I could clarify
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
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
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
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
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
On Thu, 2020-12-31 at 02:50 +, Peter Stuge wrote: > Michał Górny wrote: > > > > I think the three main ways forward from here would be to either: > > > > > > > > 1. Keep LibreSSL for indefinite time (possibly masked) > > > > 2. Eventually move LibreSSL to libressl overlay. > > > > 3. Eventually remove LibreSSL. > > > > > > 4. A libressl or libressl-libtls ebuild installs only libtls. > > > > dev-libs/libretls already does that. > > dev-libs/libretls doesn't install a libressl libtls. Yes, it does. Have you actually looked at it? It's the same exact code. > It's clear now that you want to hinder that in Gentoo at any cost to > the community, but that's not useful, so please take a step back unless > you are actually going to be constructive. I'd really appreciate if you stopped the emotional arguments and ad hominem attacks. I think it is pretty clear that I'm putting a lot of effort to find a good solution, and your aggression is very unwelcome. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
On Thu, 2020-12-31 at 02:50 +, Peter Stuge wrote: > Michał Górny wrote: > > > > I think the three main ways forward from here would be to > > > > either: > > > > > > > > 1. Keep LibreSSL for indefinite time (possibly masked) > > > > 2. Eventually move LibreSSL to libressl overlay. > > > > 3. Eventually remove LibreSSL. > > > > > > 4. A libressl or libressl-libtls ebuild installs only libtls. > > > > dev-libs/libretls already does that. > > dev-libs/libretls doesn't install a libressl libtls. > > This thread is obviously about how the libressl implementation remains > in use. > > It's clear now that you want to hinder that in Gentoo at any cost to > the community, but that's not useful, so please take a step back > unless > you are actually going to be constructive. > > My proposition 4. (which I suggested already earlier - you shouldn't > have ignored it) is obviously not about having any libtls provider in > the tree, but to model reality accurately and ensure that libretls is > the primary and prefered libtls provider, since it is literally the > libtls upstream. > > 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. > > > //Peter > Patches welcome.
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
On Wed, Dec 30, 2020 at 9:50 PM Peter Stuge wrote: > > Michał Górny wrote: > > > > I think the three main ways forward from here would be to either: > > > > > > > > 1. Keep LibreSSL for indefinite time (possibly masked) > > > > 2. Eventually move LibreSSL to libressl overlay. > > > > 3. Eventually remove LibreSSL. > > > > > > 4. A libressl or libressl-libtls ebuild installs only libtls. > > > > dev-libs/libretls already does that. > > dev-libs/libretls doesn't install a libressl libtls. > > This thread is obviously about how the libressl implementation remains > in use. > > It's clear now that you want to hinder that in Gentoo at any cost to > the community, but that's not useful, so please take a step back unless > you are actually going to be constructive. > > My proposition 4. (which I suggested already earlier - you shouldn't > have ignored it) is obviously not about having any libtls provider in > the tree, but to model reality accurately and ensure that libretls is > the primary and prefered libtls provider, since it is literally the > libtls upstream. > > 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? Anyway, it seems like the people maintaining libressl in Gentoo are really not interested in keeping it going. A libtls wrapper around openssl seems much more manageable to me, and that should probably be the default option for people.
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
Michał Górny wrote: > > > I think the three main ways forward from here would be to either: > > > > > > 1. Keep LibreSSL for indefinite time (possibly masked) > > > 2. Eventually move LibreSSL to libressl overlay. > > > 3. Eventually remove LibreSSL. > > > > 4. A libressl or libressl-libtls ebuild installs only libtls. > > dev-libs/libretls already does that. dev-libs/libretls doesn't install a libressl libtls. This thread is obviously about how the libressl implementation remains in use. It's clear now that you want to hinder that in Gentoo at any cost to the community, but that's not useful, so please take a step back unless you are actually going to be constructive. My proposition 4. (which I suggested already earlier - you shouldn't have ignored it) is obviously not about having any libtls provider in the tree, but to model reality accurately and ensure that libretls is the primary and prefered libtls provider, since it is literally the libtls upstream. 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. //Peter
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
On Wed, 2020-12-30 at 15:02 +, Peter Stuge wrote: > Michał Górny wrote: > > let's summarize what was said so far. > > Thanks for the good summary! > > > > I think the three main ways forward from here would be to either: > > > > 1. Keep LibreSSL for indefinite time (possibly masked) > > 2. Eventually move LibreSSL to libressl overlay. > > 3. Eventually remove LibreSSL. > > 4. A libressl or libressl-libtls ebuild installs only libtls. dev-libs/libretls already does that. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
Michał Górny wrote: > let's summarize what was said so far. Thanks for the good summary! > I think the three main ways forward from here would be to either: > > 1. Keep LibreSSL for indefinite time (possibly masked) > 2. Eventually move LibreSSL to libressl overlay. > 3. Eventually remove LibreSSL. 4. A libressl or libressl-libtls ebuild installs only libtls. //Peter
[gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
On Mon, 2020-12-28 at 09:56 +0100, Michał Górny wrote: > TL;DR: is there really a point in continuing the never-ending always- > regressing struggle towards supporting LibreSSL in Gentoo? Since the discussion has grown quite, let's summarize what was said so far. It seems that all respondents so far unanimously agree that the current state of libressl is suboptimal. Unless I've missed something, we also all agree that developers shouldn't put additional work to continue supporting it in their packages. What we don't seem to agree on is how we should proceed with libressl itself and its existing support in the future. I think the key points right now are that: 1. Users shouldn't take switching between OpenSSL and LibreSSL lightly. 2. We should probably discourage users from using LibreSSL on new systems for the time being. 3. We need to establish the way forward and inform the users about it. 4. We should probably wait for USE=bindist updates (due to patents expiring) and dev-libs/libretls support (whenever possible) before doing anything. In my opinion, the bare minimum we should do is to mask the libressl flag. This should ensure that users do not take it lightly, and can get an appropriate warning (from the mask message) if they really wish to switch. The downside of that is that it will implicitly force switching back existing systems, unless sysadmins take care to unmask the flag first. I think this can be solved by issuing a news item in advance. However, if we stop proactive downstream patching of LibreSSL support (which we seem to agree on), the existing LibreSSL systems may become unmaintainable (I can already imagine the super-unreadable Portage slot conflict messages). A reasonable compromise could be to maintain the necessary patching in libressl overlay. If LibreSSL team (or anybody else) is willing to take care of that, we should mention that in the news item. The fate of LibreSSL is a congestion point here. While I don't mind keeping it by itself, I don't think it's prudent to keep it if it becomes practically impossible to use it, and what I'd really like to avoid is giving users false hope. The news item should clearly indicate what's going to happen and at least approximately when. I think the three main ways forward from here would be to either: 1. Keep LibreSSL for indefinite time (possibly masked) but indicate that using it will become more and more difficult. Users will either have to use libressl overlay or local hacks to avoid conflicts with packages that do not support it. 2. Eventually move LibreSSL to libressl overlay. I think this is the best option if overlay is going to be actively maintained. It also opens other interesting options, such as providing a dev-libs/openssl meta-replacement to avoid the added complexity of USE=libressl while providing clean subslot rebuilds. 3. Eventually remove LibreSSL. I think that we should first reach an agreement on how to proceed, then start preparing the news item with clear deadlines for each step. -- Best regards, Michał Górny
