[gentoo-dev] [RFC] Discontinuing LibreSSL support?

[gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

Hello, developers and Gentoo LibreSSL team.

TL;DR: is there really a point in continuing the never-ending always-
regressing struggle towards supporting LibreSSL in Gentoo?


I would like to discuss the possibility of discontinuing LibreSSL
support in Gentoo in favor of sticking with OpenSSL.  Similarly how we
ended up deciding that fighting for libav was unpractical and the vast
majority of users are using ffmpeg (because they didn't really have
a choice), today it seems that LibreSSL is suffering the same fate.

LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
To be honest, I don't think so.  In 2014, it might have represented
a new quality.  But today, OpenSSL is alive and kicking, and LibreSSL
finds it hard to keep up.

The vast majority of software is not tested against LibreSSL.  While
patches are usually trivial and we have people that submit them,
I find many of them short-sighted.  Just look at [1].  Sure, it fixes
the build today but it disabled the feature for all foreseeable future.
How likely is it that somebody will submit another patch reenabling it
with a future LibreSSL version?

While normally I strongly prefer submitting such patches upstream, that
makes things even worse.  I mean, I wouldn't be surprised if there were
dozens of packages today that are crippled with LibreSSL just because
somebody fixed the build in the past and never revisited the problem.

This somewhat resembles running in circles.  Packages kept being broken
with LibreSSL because rarely anyone is using it.  And rarely anyone is
using LibreSSL because the apparent benefit (or lack thereof) does not
justify the constant breakage (plus invisible regressions).

All this considered, provided that nobody is able to find a good reason
to use LibreSSL, I would like to propose that we stop patching
packages, discontinue support for it and last rite it.


[1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: [RFC] Discontinuing LibreSSL support?

[David Seifert]

On Mon, 2020-12-28 at 09:56 +0100, Michał Górny wrote:
> Hello, developers and Gentoo LibreSSL team.
> 
> TL;DR: is there really a point in continuing the never-ending always-
> regressing struggle towards supporting LibreSSL in Gentoo?
> 
> 
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.  Similarly how we
> ended up deciding that fighting for libav was unpractical and the vast
> majority of users are using ffmpeg (because they didn't really have
> a choice), today it seems that LibreSSL is suffering the same fate.
> 
> LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
> To be honest, I don't think so.  In 2014, it might have represented
> a new quality.  But today, OpenSSL is alive and kicking, and LibreSSL
> finds it hard to keep up.
> 
> The vast majority of software is not tested against LibreSSL.  While
> patches are usually trivial and we have people that submit them,
> I find many of them short-sighted.  Just look at [1].  Sure, it fixes
> the build today but it disabled the feature for all foreseeable
> future.
> How likely is it that somebody will submit another patch reenabling it
> with a future LibreSSL version?
> 
> While normally I strongly prefer submitting such patches upstream,
> that
> makes things even worse.  I mean, I wouldn't be surprised if there
> were
> dozens of packages today that are crippled with LibreSSL just because
> somebody fixed the build in the past and never revisited the problem.
> 
> This somewhat resembles running in circles.  Packages kept being
> broken
> with LibreSSL because rarely anyone is using it.  And rarely anyone is
> using LibreSSL because the apparent benefit (or lack thereof) does not
> justify the constant breakage (plus invisible regressions).
> 
> All this considered, provided that nobody is able to find a good
> reason
> to use LibreSSL, I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.
> 
> 
> [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892
> 

As someone who joined the LibreSSL project back in the days, I second
this. The ROI given the breakages involved and, in many cases,
downstream patch carrying just doesn't seem like a positive tradeoff.
The idea was noble, but let's be honest: After 6 years, there's no end
in sight, and we seem to be going nowhere.

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Agostino Sarubbo]

On lunedì 28 dicembre 2020 09:56:19 CET Michał Górny wrote:
> I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.

+1

--
Agostino

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Hanno Böck]

If it has any weight:
I think I was the first person to build Gentoo with LibreSSL. I support
this.

I believe pretty much everything that LibreSSL originally was
(consistent codingstyle, cleanup of obsolete/dead code etc.) has
happened in OpenSSL these days. It's more that there's some myth around
LibreSSL from these early days (where the people behind it raised
back then valid criticism about OpenSSL) than any real value.

-- 
Hanno Böck
https://hboeck.de/

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Anthony G. Basile]

On 12/28/20 3:56 AM, Michał Górny wrote:
> Hello, developers and Gentoo LibreSSL team.
> 
> TL;DR: is there really a point in continuing the never-ending always-
> regressing struggle towards supporting LibreSSL in Gentoo?
> 
> 
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.  Similarly how we
> ended up deciding that fighting for libav was unpractical and the vast
> majority of users are using ffmpeg (because they didn't really have
> a choice), today it seems that LibreSSL is suffering the same fate.
> 
> LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
> To be honest, I don't think so.  In 2014, it might have represented
> a new quality.  But today, OpenSSL is alive and kicking, and LibreSSL
> finds it hard to keep up.
> 
> The vast majority of software is not tested against LibreSSL.  While
> patches are usually trivial and we have people that submit them,
> I find many of them short-sighted.  Just look at [1].  Sure, it fixes
> the build today but it disabled the feature for all foreseeable future.
> How likely is it that somebody will submit another patch reenabling it
> with a future LibreSSL version?
> 
> While normally I strongly prefer submitting such patches upstream, that
> makes things even worse.  I mean, I wouldn't be surprised if there were
> dozens of packages today that are crippled with LibreSSL just because
> somebody fixed the build in the past and never revisited the problem.
> 
> This somewhat resembles running in circles.  Packages kept being broken
> with LibreSSL because rarely anyone is using it.  And rarely anyone is
> using LibreSSL because the apparent benefit (or lack thereof) does not
> justify the constant breakage (plus invisible regressions).
> 
> All this considered, provided that nobody is able to find a good reason
> to use LibreSSL, I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.
> 
> 
> [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892
> 

I'm the current project lead.  I inherited it back in the day from
hasufel.  It originally had promise of being better than openssl with
100% compatibility.  I hung on because I trusted that team but it has
become more of a hassle than its worth.  I am in favor of removing it.
If we decide to do so, how should we proceed?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Mon, 2020-12-28 at 13:59 -0500, Anthony G. Basile wrote:
> On 12/28/20 3:56 AM, Michał Górny wrote:
> > Hello, developers and Gentoo LibreSSL team.
> > 
> > TL;DR: is there really a point in continuing the never-ending
> > always-
> > regressing struggle towards supporting LibreSSL in Gentoo?
> > 
> > 
> > I would like to discuss the possibility of discontinuing LibreSSL
> > support in Gentoo in favor of sticking with OpenSSL.  Similarly how
> > we
> > ended up deciding that fighting for libav was unpractical and the
> > vast
> > majority of users are using ffmpeg (because they didn't really have
> > a choice), today it seems that LibreSSL is suffering the same fate.
> > 
> > LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
> > To be honest, I don't think so.  In 2014, it might have represented
> > a new quality.  But today, OpenSSL is alive and kicking, and
> > LibreSSL
> > finds it hard to keep up.
> > 
> > The vast majority of software is not tested against LibreSSL. 
> > While
> > patches are usually trivial and we have people that submit them,
> > I find many of them short-sighted.  Just look at [1].  Sure, it
> > fixes
> > the build today but it disabled the feature for all foreseeable
> > future.
> > How likely is it that somebody will submit another patch reenabling
> > it
> > with a future LibreSSL version?
> > 
> > While normally I strongly prefer submitting such patches upstream,
> > that
> > makes things even worse.  I mean, I wouldn't be surprised if there
> > were
> > dozens of packages today that are crippled with LibreSSL just
> > because
> > somebody fixed the build in the past and never revisited the
> > problem.
> > 
> > This somewhat resembles running in circles.  Packages kept being
> > broken
> > with LibreSSL because rarely anyone is using it.  And rarely anyone
> > is
> > using LibreSSL because the apparent benefit (or lack thereof) does
> > not
> > justify the constant breakage (plus invisible regressions).
> > 
> > All this considered, provided that nobody is able to find a good
> > reason
> > to use LibreSSL, I would like to propose that we stop patching
> > packages, discontinue support for it and last rite it.
> > 
> > 
> > [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892
> > 
> 
> I'm the current project lead.  I inherited it back in the day from
> hasufel.  It originally had promise of being better than openssl with
> 100% compatibility.  I hung on because I trusted that team but it has
> become more of a hassle than its worth.  I am in favor of removing
> it.
> If we decide to do so, how should we proceed?

I think the usual plan for this kind of thing is to:

1. Issue a news item with the planned cutoff date, and suggest people
that they can set USE=-libressl to switch earlier.

2. At the cutoff date, use.mask libressl flag.

3. package.mask libressl itself to give people a clear message.


I might be wrong but I think the update should proceed cleanly with
--changed-use/--newuse.  The PM will trigger the rebuilds,
and preserved-libs should take care of keeping libressl libs for
as long as necessary (yeah, I know relying on preserved-libs sucks).

The only problem that I can think of are packages that depend
on libressl specifically and do not support openssl.  I don't think we
have anything like that but I'll double check.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 668 bytes --]

On 12/28/20 8:55 PM, Michał Górny wrote:
> I might be wrong but I think the update should proceed cleanly with
> --changed-use/--newuse.

Maybe it is worth to tell people within the news item to run sth like

   emerge --fetchonly dev-libs/openssl net-misc/openssh net-misc/wget

before (to have at least the wget sources at disk before it becomes 
temporary broken during @preserved-rebuild) ?

IIRC I needed it to switch from OpenSSL to LIbreSSL at my server and 
desktop (and coded it therefore into the tinderbox script too).


Beside that: years ago I really believed in LibreSSL
- *schnief*, *schluchz*

-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.

I think that's a horrible idea, since Gentoo is about choice and this
particular component is one of the most important in a system.

But "support" can mean different things...


> LibreSSL users, does LibreSSL today have any benefit over OpenSSL?

Yes, at least two:

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.

B. It brings its own TLS API, a unique feature which by itself warrants
the package.


> All this considered, provided that nobody is able to find a good reason
> to use LibreSSL, I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.

There is no reason at all to do all three of those atomically:

1. Stop patching packages to make them build also against libressl
2. Stop maintaining libressl-*.ebuild
3. package.mask

I think the complaint is really only about 1. and I can understand
that the effort here outweighs the perceived benefit, that's fine,
I don't think it's the responsibility of Gentoo developers to patch
the world to build also against libressl.

But as long as a single package can be built with either openssl or
libressl without changes I consider it appropriate to maintain both
libressl ebuilds and either virtual/openssl or another way to decide
system-wide to use libressl instead of openssl. This remains very
valuable especially for non-releng stages.

More elaborate OpenSSL API users can (arguably should) just block on
libressl instead of requiring patch work.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[m1027]

I've been kindly asked by a gentoo dev to send my two pence in here:

peter:

> Michał Górny wrote:
> 
> > LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
> 
> Yes, at least two:
> 
> [...]
> 
> B. It brings its own TLS API, a unique feature which by itself warrants
> the package.

Yeah, since openssl and libressl cannot be installed at the same
time, I wonder what will be the future of libtls?  To recall, it is
a "a new TLS library, designed to make it easier to write foolproof
applications" (see libressl.org).  I've been using it for some time.
It's great, and it is part of libressl.

Another thing: Besides libressl there are boringssl and others. Even
if still not the case (?), having virtual alternatives should in
theory help keeping polished interfaces. If for whatever reason this
not the case in practise, I believe dropping the alternatives should
be worse.

I cannot judge on the work the maintainers have to deal with
compatibility issues between libressl and openssl, though. Let me
know when I can help.

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Mon, 2020-12-28 at 22:00 +0000, Peter Stuge wrote:
> Michał Górny wrote:
> > I would like to discuss the possibility of discontinuing LibreSSL
> > support in Gentoo in favor of sticking with OpenSSL.
> 
> I think that's a horrible idea, since Gentoo is about choice and this
> particular component is one of the most important in a system.
> 
> But "support" can mean different things...
> 
> 
> > LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
> 
> Yes, at least two:
> 
> 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.

> 
> B. It brings its own TLS API, a unique feature which by itself
> warrants
> the package.

...which by itself has no future and only means some people will create
less portable applications and then regret it.

> 
> 
> > All this considered, provided that nobody is able to find a good
> > reason
> > to use LibreSSL, I would like to propose that we stop patching
> > packages, discontinue support for it and last rite it.
> 
> There is no reason at all to do all three of those atomically:
> 
> 1. Stop patching packages to make them build also against libressl
> 2. Stop maintaining libressl-*.ebuild
> 3. package.mask
> 
> I think the complaint is really only about 1. and I can understand
> that the effort here outweighs the perceived benefit, that's fine,
> I don't think it's the responsibility of Gentoo developers to patch
> the world to build also against libressl.
> 
> But as long as a single package can be built with either openssl or
> libressl without changes I consider it appropriate to maintain both
> libressl ebuilds and either virtual/openssl or another way to decide
> system-wide to use libressl instead of openssl. This remains very
> valuable especially for non-releng stages.
> 
> More elaborate OpenSSL API users can (arguably should) just block on
> libressl instead of requiring patch work.

It's all nice theory but in practice it means that nobody will be able
to install libressl because some important system packages will block
it.  So we'd effectively waste our users' time pretending that we do
support LibreSSL, while anyone actually trying it will hit a brick
wall.

This sounds like the argument 'let's not remove broken packages, people
can read the 5 page forum thread on how to get them to work,
somewhat!'.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

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

Did anyone gather actual numbers?


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


> > More elaborate OpenSSL API users can (arguably should) just block on
> > libressl instead of requiring patch work.
> 
> It's all nice theory but in practice it means that nobody will be able
> to install libressl because some important system packages will block it.

Gentoo can't be expected to do magic. If libressl would conflict on another
system then of course it will on Gentoo too. Give users more credit here.

Also, think more about other use cases than your own. I mentioned one;
non-releng stages. The point here is that it's possible to deliberately
create a system using libressl by making tradeoffs, e.g. not using some
"important" system packages which would block it.

Finally, I find it quite beautiful if Gentoo can clearly show that
important system packages have slipped far down a monoculture slope -
this is a great incentive for new projects which tackle creating
alternatives for those packages.


> waste our users' time pretending that we do support LibreSSL,
> while anyone actually trying it will hit a brick wall.

You shouldn't pretend to be something you are not. With a little effort
to set users' expectations according to the technical reality (a function
of upstreams; rather unrelated to Gentoo) I don't expect wasted time.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[David Haller]

Hello,

On Mon, 28 Dec 2020, Michal Górny wrote:
>The only problem that I can think of are packages that depend
>on libressl specifically and do not support openssl.  I don't think we
>have anything like that but I'll double check.

A naive check finds these:

Depends unconditionally on dev-libs/libressl:
app-crypt/acme-client

Depends conditionally on only dev-libs/libressl (no openssl alternative):
net-misc/s6-networking
net-misc/openntpd

HTH,
-dnh

-- 
New, from IKEA: DARCKENSE, the chair. Available in white only.
All-natural materials!                      -- Niklas Karlsson

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Marcel Schilling]

On Mon, Dec 28, 2020 at 11:33:36PM +0100, Michał Górny wrote:
> On Mon, 2020-12-28 at 22:00 +0000, Peter Stuge wrote:
> > Michał Górny wrote:
> > > LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
> > 
> > Yes, at least two:
> > 
> > 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 just want to comment that I switched to LibreSSL on several Gentoo
systems years ago and never had any major issues.
I run both desktop and server systems with LibreSSL, based on X and
Wayland. The only issues I ran into is a slight lag of the overlay
behind the main tree so once in a while I had to mask a new version of
some package for a week or so.
So from a pure user perspective, thing change would mean a risky update
to systems running stable for years with no gain whatsoever.
So even if LibreSSL does not provide any advantage over OpenSSL
(anymore), dropping support would do harm.
That said, I do understand maintainer burden and I will probably be fine
with such a change. But I have to say that over the last ten years,
Gentoo does feel a lot less focussed on choice than it used to and I am
counting the days until is deemed 'unpractical' to support legacy boot,
non-systemd init or 'exotic' arches. ;-)

Best,
Marcel

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2770 bytes --]


> On 29 Dec 2020, at 09:13, Marcel Schilling <marcel.schilling@mdc-berlin.de> wrote:
> 
> 
> I just want to comment that I switched to LibreSSL on several Gentoo
> systems years ago and never had any major issues.
> I run both desktop and server systems with LibreSSL, based on X and
> Wayland. The only issues I ran into is a slight lag of the overlay
> behind the main tree so once in a while I had to mask a new version of
> some package for a week or so.

It is largely one person who is under a lot of stress to provide updated
patches ASAP. Some upstreams have made clear they will never
accept LibreSSL patches and life becomes harder as they adopt
new APIs not yet supported in the Libre variant.

TL;DR: I’d be fine with keeping LibreSSL if we had (an influx of) people
coming up with patches that are sustainable, upstreamed, and not just
crippling functionality.

> So from a pure user perspective, thing change would mean a risky update
> to systems running stable for years with no gain whatsoever.

This isn’t quite right. Users cannot upgrade to new versions of software,
possibly with security fixes, until a new patch is created and applied.

This recently happened with mupdf.

One of our developers runs several high-bandwidth Tor relays which
were broken with LibreSSL and still haven’t been fixed. But I accept
that you’ve had a pain-free experience.

> So even if LibreSSL does not provide any advantage over OpenSSL
> (anymore), dropping support would do harm.
> That said, I do understand maintainer burden and I will probably be fine
> with such a change. But I have to say that over the last ten years,
> Gentoo does feel a lot less focussed on choice than it used to and I am
> counting the days until is deemed 'unpractical' to support legacy boot,
> non-systemd init or 'exotic' arches. ;-)
> 

I don’t think this is true. We support equality of openrc vs systemd and
if you think there’s deficits there, please let us know - although of course
help is welcome (and needed for OpenRC).

And on arches, I spend a lot of my time testing packages on various
exotic architectures, so it’d be good to have some concrete examples
of what’s bothering you.

I don’t think being realistic about what we can support is wrong,
but I’m also not sure we’ve been particularly aggressive or wrong
with any of those decisions...

> Best,
> Marcel

—
My position is that I’d prefer to just mask it and make clear it’s
unsupported rather than remove at all.

There’s little to be gained from fully removing - we can just treat it like
musl/prefix/whatever else, i.e. a niche thing which we support with best-effort
(and it might be a bit patchy).

Thanks,
Sam


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]



> On 28 Dec 2020, at 10:02, Hanno Böck <hanno@gentoo.org> wrote:
> 
> If it has any weight:
> I think I was the first person to build Gentoo with LibreSSL. I support
> this.
> 

I’m pleased to have yours and blueness’ input. Really, I think going
is probably best. Just make it clear it can come back with some
new backing, if that ever happens.

Thinking about it some more, we recently had QtNetwork users without
security patches for a few weeks because (and this is not his fault) there’s
only a bus factor of 1 for updating compatibility on every point release of Qt.

I’m also unconvinced that if we suddenly lost LibreSSL compatibility in some
@system or otherwise popular package we could restore functionality in any
reasonable timeframe.

Bit sad to be here, but here we are.

> I believe pretty much everything that LibreSSL originally was
> (consistent codingstyle, cleanup of obsolete/dead code etc.) has
> happened in OpenSSL these days. It's more that there's some myth around
> LibreSSL from these early days (where the people behind it raised
> back then valid criticism about OpenSSL) than any real value.

This is exactly my experience.

> 
> --
> Hanno Böck
> https://hboeck.de/
> 


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Aaron Bauman]

On December 29, 2020 4:39:06 AM EST, "Michał Górny" <mgorny@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.

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > 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?

No, I'm rather asking to change the level of commitment.

I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
to continuosly patch the entire world for libressel.

I'm asking to stop doing that, yet still enable the choice between
openssl and libressl where that is possible without patches, even
if that's only openntpd and one other package.

The method for that choice could of course depend on the number of
packages where it applies.


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

I believe I'm asking for the opposite. I think it's fine to say that
libressl has to be a deliberate choice rather than a default.


> > Did anyone gather actual numbers?
> 
> $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l
> 61

I'm more interested in the number of packages which can use either
library without patches (like openntpd?). This may be tricky to find out. :\


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

You absolutely have a right to your opinion but you stated it as fact,
that made me react so strongly.


> I don't dispute whether it's good.  I dispute whether tightly binding
> it to a problematic LibreSSL is a good idea.

I agree with this, but only in cases where libressl is indeed problematic.

I can think of systems where it isn't, there the choice is a good thing.


> Actually, I see that someone has apparently forked libtls into libretls
> (the irony!) that works against OpenSSL [1].

To me, that proves value in the libtls API and in keeping libressl in
the tree in some capacity, even if not as an alternative to openssl.

Maybe with a USE flag which makes it install only libtls (built from
libressl static libs), which could be one provider for a virtual/libtls.

Note: I'm not at all expecting anyone to do such work for me, I just
don't want it to become impossible (libressl mask) or any existing
effort supporting something like the above to be sunset.

Does that make sense?


Thanks!

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Andrey Utkin]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

I agree with the proposal to sunset LibreSSL.
Supporting it benefits very few users due to how non-universal the support of
this option is. I see it as entirely sensible choice on apps' upstreams part to
not collaborate on libressl support, motivation being focusing on more typical
user setups.

But I have one loosely related question. About USE=bindist of openssl & openssh.

My impression is that when you spin up a new Gentoo setup from stage3, very
early on you are typically forced by situations to switch off USE=bindist for
openssl and openssh. I conclude that one can't redistribute more elaborate
system images and binpkgs because of this.

However there's no `bindist` flag and therefore no such situation with libressl
package. I never did good research of why this is so, so I am still wondering:
what does that mean in practice?

Does this mean libressl has some advantage for binary redistributability of
elaborate system images and binary packages?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Mikle Kolyada]

28.12.2020 11:56, Michał Górny пишет:
>   I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.
>
I second this.

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Tue, 2020-12-29 at 11:29 +0000, Peter Stuge wrote:
> Michał Górny wrote:
> > > 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?
> 
> No, I'm rather asking to change the level of commitment.
> 
> I agree completely that it's unreasonable for Gentoo (worse, 1
> person!)
> to continuosly patch the entire world for libressel.
> 
> I'm asking to stop doing that, yet still enable the choice between
> openssl and libressl where that is possible without patches, even
> if that's only openntpd and one other package.
> 
> The method for that choice could of course depend on the number of
> packages where it applies.

I'm pretty sure that soon enough one of Portage/Python dependencies is
going to become a blocker for everything.

> > 
> > > Did anyone gather actual numbers?
> > 
> > $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l
> > 61
> 
> I'm more interested in the number of packages which can use either
> library without patches (like openntpd?). This may be tricky to find
> out. :\

It's never that simple.  Roughly speaking, there are 3 levels
of incompatibility with LibreSSL:

1. Stuff that does not build against LibreSSL.

2. Stuff that builds just fine but fails at runtime in unpredictable
ways (e.g. Tor mentioned today).

3. Stuff that builds and works 'fine' but ends up being crippled (e.g.
doesn't support new algorithms).

The first one is somewhat easy to test (e.g. via tinderbox).  The other
two are very hard.

> > > > 
> > Actually, I see that someone has apparently forked libtls into
> > libretls
> > (the irony!) that works against OpenSSL [1].
> 
> To me, that proves value in the libtls API and in keeping libressl in
> the tree in some capacity, even if not as an alternative to openssl.
> 
> Maybe with a USE flag which makes it install only libtls (built from
> libressl static libs), which could be one provider for a
> virtual/libtls.

I don't see why we would put an effort into that.  I've just packaged
dev-libs/libretls, and the maintenance effort in it seems really
minimal.  Trying to get the same result from libressl is just repeating
the work.


-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Mon, 2020-12-28 at 23:26 +0100, m1027 wrote:
> I've been kindly asked by a gentoo dev to send my two pence in here:
> 
> peter:
> 
> > Michał Górny wrote:
> > 
> > > LibreSSL users, does LibreSSL today have any benefit over
> > > OpenSSL?
> > 
> > Yes, at least two:
> > 
> > [...]
> > 
> > B. It brings its own TLS API, a unique feature which by itself
> > warrants
> > the package.
> 
> Yeah, since openssl and libressl cannot be installed at the same
> time, I wonder what will be the future of libtls?  To recall, it is
> a "a new TLS library, designed to make it easier to write foolproof
> applications" (see libressl.org).  I've been using it for some time.
> It's great, and it is part of libressl.

As noted in another fork of this thread, libtls is now provided
by dev-libs/libretls which works against OpenSSL.

> Another thing: Besides libressl there are boringssl and others. Even
> if still not the case (?), having virtual alternatives should in
> theory help keeping polished interfaces. If for whatever reason this
> not the case in practise, I believe dropping the alternatives should
> be worse.

I don't think these alternatives were ever meant to be used system-
wide.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Mon, 2020-12-28 at 21:42 +0100, Toralf Förster wrote:
> On 12/28/20 8:55 PM, Michał Górny wrote:
> > I might be wrong but I think the update should proceed cleanly with
> > --changed-use/--newuse.
> 
> Maybe it is worth to tell people within the news item to run sth like
> 
>    emerge --fetchonly dev-libs/openssl net-misc/openssh net-misc/wget
> 
> before (to have at least the wget sources at disk before it becomes 
> temporary broken during @preserved-rebuild) ?
> 
> IIRC I needed it to switch from OpenSSL to LIbreSSL at my server and 
> desktop (and coded it therefore into the tinderbox script too).

Thanks, that's a very good suggestion.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Tue, 2020-12-29 at 06:33 +0100, David Haller wrote:
> Hello,
> 
> On Mon, 28 Dec 2020, Michal Górny wrote:
> > The only problem that I can think of are packages that depend
> > on libressl specifically and do not support openssl.  I don't think
> > we
> > have anything like that but I'll double check.
> 
> A naive check finds these:
> 
> Depends unconditionally on dev-libs/libressl:
> app-crypt/acme-client

Furthermore, it seems to be specifically relying on libressl internals
(i.e. contents of opaque structures).  Given that it doesn't build with
gcc-10 and there's a lot of ACME clients around, I suppose we can last
rite it.

> Depends conditionally on only dev-libs/libressl (no openssl
> alternative):
> net-misc/s6-networking

This dependency has been removed yesterday.

> net-misc/openntpd

I've just tested it and it builds fine against dev-libs/libretls.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Jaco Kroon]

Hi Peter,

On 2020/12/29 13:29, Peter Stuge wrote:
> Michał Górny wrote:
>>> 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?
> No, I'm rather asking to change the level of commitment.
>
> I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> to continuosly patch the entire world for libressel.
>
> I'm asking to stop doing that, yet still enable the choice between
> openssl and libressl where that is possible without patches, even
> if that's only openntpd and one other package.

Are you willing to put in the work to allow installing openssl and
libressl concurrently on the same system?

And I raise this, because as others have insinuated, currently it's one
or the other, they can't co-exist, and there are a great many number of
packages that doesn't work with libressl.  The only real solution then
to make libressl viable is to make it co-exist with openssl reliably.

Of course there are various strategies (or combination of), to mention
but a few:

1.  Use a virtual/??? (but since the APIs aren't compatible despite the
libressl promise thereto ...)
2.  Install them into different prefixes (eg /usr/lib/openssl +
/usr/lib/libressl and have the linker link to a specific version,
/usr/include/{openssl,libressl} too).
3.  Make ssl USE flag another single-choice USE_EXPAND, posibly by way
of openssl.eclass.

My personal support currently goes towards at the very least masking
libressl, but removal unless someone is going to put in the effort
towards the above.  Happy to help with patching on my own packages, but
without concurrent install of libre+openssl it's a massive workload to
test for me, so not happy with current state either.

+1 for removal given current state, but would be in willing and in
support of updating the packages I maintain to assist with libressl
support if the eco system can be improved.

Kind Regards,
Jaco

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 448 bytes --]

On 12/29/20 1:23 PM, Michał Górny wrote:
> 2. Stuff that builds just fine but fails at runtime in unpredictable
> ways (e.g. Tor mentioned today).

FWIW that's exactly what I do suffer from at my Tor relays.

Beside that a naive question: Wouldn't it be siufficient to just 
have/keep the libressl overlay/repo?
So whoever wants to use LibreSSL in future just configure its portage to 
use that?

-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> 1. Stuff that does not build against LibreSSL.
> 2. Stuff that builds just fine but fails at runtime in unpredictable
> ways (e.g. Tor mentioned today).
> 3. Stuff that builds and works 'fine' but ends up being crippled (e.g.
> doesn't support new algorithms).
> 
> The first one is somewhat easy to test (e.g. via tinderbox).  The other
> two are very hard.

Nod.


> > > Actually, I see that someone has apparently forked libtls into
> > > libretls (the irony!) that works against OpenSSL [1].
> > 
> > To me, that proves value in the libtls API and in keeping libressl in
> > the tree in some capacity, even if not as an alternative to openssl.
> > 
> > Maybe with a USE flag which makes it install only libtls (built from
> > libressl static libs), which could be one provider for a
> > virtual/libtls.
> 
> I don't see why we would put an effort into that.

In my very next sentence (not quoted in your reply) I wrote explicitly
that I do /not/ ask anyone to do so, but ask that you don't hinder it
by masking libressl and also don't remove existing work potentially
supporting such efforts, ie. the libressl ebuild.


> I've just packaged dev-libs/libretls

Thanks! That seems useful.


> Trying to get the same result from libressl is just repeating the work.

Maybe for you, and I'm saying that you should be able to make that choice
for your systems, but also that you should not hinder others from making
another choice, where that's possible and as I wrote without needing
Gentoo to patch the world.


Thanks a lot

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Tue, 2020-12-29 at 13:41 +0100, Toralf Förster wrote:
> On 12/29/20 1:23 PM, Michał Górny wrote:
> > 2. Stuff that builds just fine but fails at runtime in
> > unpredictable
> > ways (e.g. Tor mentioned today).
> 
> FWIW that's exactly what I do suffer from at my Tor relays.
> 
> Beside that a naive question: Wouldn't it be siufficient to just 
> have/keep the libressl overlay/repo?
> So whoever wants to use LibreSSL in future just configure its portage
> to 
> use that?
> 

I don't have a problem with that.  What I do have a problem with is:

1. People submitting bad patches upstream (but I guess that's
inevitable).

2. Maintaining downstream patches forever.

3. Being blocked by libressl patches no longer applying.

I wouldn't mind keeping LibreSSL if it was possible to actually
maintain it without causing these problems.  But I don't think it's
possible to do that.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > net-misc/openntpd
> 
> I've just tested it and it builds fine against dev-libs/libretls.

I hope you're not planning to suggest that dev-libs/libretls should
be the only libtls on Gentoo, since that would be an arbitrary and
artificial limitation - the very opposite of choice. I'm strongly
against that.


Jaco Kroon wrote:
> > I'm asking to stop doing that, yet still enable the choice between
> > openssl and libressl where that is possible without patches, even
> > if that's only openntpd and one other package.
> 
> Are you willing to put in the work to allow installing openssl and
> libressl concurrently on the same system?

I'm willing to help. I know that it's one or the other. And I have
experience with distributions making arbitrary decisions about libraries,
and I think I have an idea about the challenges and possibilities.


> The only real solution then to make libressl viable is to make it
> co-exist with openssl reliably.

Ack.


> Of course there are various strategies (or combination of), to mention
> but a few:
> 
> 1.  Use a virtual/??? (but since the APIs aren't compatible despite the
> libressl promise thereto ...)
> 2.  Install them into different prefixes (eg /usr/lib/openssl +
> /usr/lib/libressl and have the linker link to a specific version,
> /usr/include/{openssl,libressl} too).
> 3.  Make ssl USE flag another single-choice USE_EXPAND, posibly by way
> of openssl.eclass.

These are all interesting and I think worth exploring! But also
non-trivial, so maybe better saved for later?

What do you think about my suggestion in a previous email to have the
libressl ebuild install only libtls .so and .a files built from static
libs/objects, so that there are no conflicting shared objects?

I can certainly help accomplish that if there is interest.


> would be in willing and in support of updating the packages I maintain
> to assist with libressl support if the eco system can be improved.

Cool! I really appreciate your openness. I'm asking essentially to
keep options open, so that the ecosystem can be improved step by step.


Thanks

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Tue, 2020-12-29 at 14:39 +0200, Jaco Kroon wrote:
> 2.  Install them into different prefixes (eg /usr/lib/openssl +
> /usr/lib/libressl and have the linker link to a specific version,
> /usr/include/{openssl,libressl} too).

For the record, this is something I've been wondering about for a long
time.  However, there are two problems with that: a small one
and a huge one.

The small problem is that this requires a lot of additional downstream
work.  I mean, you have to explicitly support the choice in ebuilds,
and this means making things even harder for newcomers.

The big problem is that (unless I'm mistaken) we won't be able to load
LibreSSL and OpenSSL to the same executable.  So we'd actually have to
enforce that the whole link chain links to the same SSL provider,
and effectively land pretty close to where we are now.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > 2.  Install them into different prefixes (eg /usr/lib/openssl +
> > /usr/lib/libressl and have the linker link to a specific version,
> > /usr/include/{openssl,libressl} too).
> 
> For the record, this is something I've been wondering about for a long
> time.  However, there are two problems with that: a small one
> and a huge one.
> 
> The small problem is that this requires a lot of additional downstream
> work.  I mean, you have to explicitly support the choice in ebuilds,
> and this means making things even harder for newcomers.

pkg-config/pkgconf and .pc files can help with this part, taking care
of all abstraction if/when downstream uses a libressl.pc.


> The big problem is that (unless I'm mistaken) we won't be able to load
> LibreSSL and OpenSSL to the same executable.  So we'd actually have to
> enforce that the whole link chain links to the same SSL provider,
> and effectively land pretty close to where we are now.

I'd suggest investigating whether symbol versioning could help with this,
or if the only way forward would indeed be to require some symbol
mangling/rewriting.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[David Seifert]

On Tue, 2020-12-29 at 13:21 +0000, Peter Stuge wrote:
> Michał Górny wrote:
> > > 2.  Install them into different prefixes (eg /usr/lib/openssl +
> > > /usr/lib/libressl and have the linker link to a specific version,
> > > /usr/include/{openssl,libressl} too).
> > 
> > For the record, this is something I've been wondering about for a
> > long
> > time.  However, there are two problems with that: a small one
> > and a huge one.
> > 
> > The small problem is that this requires a lot of additional
> > downstream
> > work.  I mean, you have to explicitly support the choice in ebuilds,
> > and this means making things even harder for newcomers.
> 
> pkg-config/pkgconf and .pc files can help with this part, taking care
> of all abstraction if/when downstream uses a libressl.pc.

As we have learned from the ncurses[tinfo] debacle, 80% of build systems
don't use the .pc files, and just guess "-lssl" flags and a bunch of
include dirs. Hence, this boils down to patching a mountain of build
systems again, which while being the ultimately correct way, is a pipe
dream.

> > The big problem is that (unless I'm mistaken) we won't be able to
> > load
> > LibreSSL and OpenSSL to the same executable.  So we'd actually have
> > to
> > enforce that the whole link chain links to the same SSL provider,
> > and effectively land pretty close to where we are now.
> 
> I'd suggest investigating whether symbol versioning could help with
> this,
> or if the only way forward would indeed be to require some symbol
> mangling/rewriting.

While this sounds like a theoretical solution, it isn't tractable
because
1. We're inventing our own ABI that is incompatible with everyone else's
2. We'd have to maintain a huge swamp of downstream patches
3. ABI can still break even with perfect symbol versioning

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Alexey Sokolov]

вт, 29 дек. 2020 г. в 13:33, David Seifert <soap@gentoo.org>:
>
> On Tue, 2020-12-29 at 13:21 +0000, Peter Stuge wrote:
> > Michał Górny wrote:
> > > > 2.  Install them into different prefixes (eg /usr/lib/openssl +
> > > > /usr/lib/libressl and have the linker link to a specific version,
> > > > /usr/include/{openssl,libressl} too).
> > >
> > > For the record, this is something I've been wondering about for a
> > > long
> > > time.  However, there are two problems with that: a small one
> > > and a huge one.
> > >
> > > The small problem is that this requires a lot of additional
> > > downstream
> > > work.  I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> >
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
>
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs. Hence, this boils down to patching a mountain of build
> systems again, which while being the ultimately correct way, is a pipe
> dream.

If it's the ultimately correct way, such patches can be sent upstream,
regardless of whether libressl stays.

>
> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load
> > > LibreSSL and OpenSSL to the same executable.  So we'd actually have
> > > to
> > > enforce that the whole link chain links to the same SSL provider,
> > > and effectively land pretty close to where we are now.
> >
> > I'd suggest investigating whether symbol versioning could help with
> > this,
> > or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
>
> While this sounds like a theoretical solution, it isn't tractable
> because
> 1. We're inventing our own ABI that is incompatible with everyone else's
> 2. We'd have to maintain a huge swamp of downstream patches
> 3. ABI can still break even with perfect symbol versioning
>
>

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

David Seifert wrote:
> > > I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> > 
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
> 
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs.

Did the debacle actually involve -lssl ?

I guess that it depends on the particular library - with an old library
such as ncurses I can imagine that .pc is much less established, and
I have indeed seen pretty ugly OpenSSL detection in configure.acs,
they could still remain, and would then simply never catch libressl,
I think that would be fine.


> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load LibreSSL and OpenSSL to the same executable.
> > 
> > I'd suggest investigating whether symbol versioning could help with
> > this, or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
> 
> While this sounds like a theoretical solution, it isn't tractable because
> 1. We're inventing our own ABI that is incompatible with everyone else's

ABI for a given library doesn't neccessarily matter beyond the
individual system, does it?

For something like reproducible builds of course it does.


> 2. We'd have to maintain a huge swamp of downstream patches

Nono, no patches of course, it would have to be automatic, if only for the
local system.


> 3. ABI can still break even with perfect symbol versioning

Oh? This may be unrelated, but can you tell more or provide a pointer?


Thanks!

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[m1027]

> > On 29 Dec 2020, at 09:13, Marcel Schilling
> > <marcel.schilling@mdc-berlin.de> wrote:
> > 
> > I just want to comment that I switched to LibreSSL on several
> > Gentoo systems years ago and never had any major issues.  I run
> > both desktop and server systems with LibreSSL, based on X and
> > Wayland. The only issues I ran into is a slight lag of the
> > overlay behind the main tree so once in a while I had to mask a
> > new version of some package for a week or so.

Let me just come back on the different views here:

@marcel: Exactly the same here. Smoothly running libressl on dozens
of systems here, from embedded to ryzen servers, even on Gnome
desktops. At least from the libressl *user's* perspective.

sam:

> TL;DR: [...libressl patches are...] just crippling functionality.

@sam: From the perspective of libressl maintainers I have had a hard
time reading this thread ;-) to learn that even security is supposed
to be an issue with libressl today!? Aren't these crippling patches
sometimes even helpful (see some apache patches) to crop unreliable
extra features? I might be wrong here. Actually I'd prefer something
'boring' and stable on ssl over new features...

Well, I cannot judge on the security issues in depth. From a short
internet scan I don't see recent libressl issues but e.g. this one
on openssl, https://www.openssl.org/news/vulnerabilities.html, only
three weeks ago.

Anyway, my personal conclusion on security:

I've once switched to libressl because of the heartbleed issue.  If
security is better with openssl these days, I'd of course switch
back.  It might be worth having some warm explanations on the
motivation in eselect NEWS, to help people out of the initial state
of shock.

> > So from a pure user perspective, thing change would mean a risky update
> > to systems running stable for years with no gain whatsoever.

Coming back on the technical way to switch back to openssl:

Thanks to Gentoo, isn't the switch back more or less something
predictable like

- removing libressl USE / CURL flags

- download everything before compiling (emerge -f ...)

- removing libressl, installing openssl, maybe wget then, followed
  by the rest?

It plead for something that actually *works* as many systems will
need that change here.

Thanks

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

> TL;DR: is there really a point in continuing the never-ending always-
> regressing struggle towards supporting LibreSSL in Gentoo?
> 
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL. 

From a team member and initial "believer", yes please. 
Libressl turns out to be more pain than gain.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Tue, 2020-12-29 at 14:57 +0100, m1027 wrote:
> > > On 29 Dec 2020, at 09:13, Marcel Schilling
> > > <marcel.schilling@mdc-berlin.de> wrote:
> > > 
> > > I just want to comment that I switched to LibreSSL on several
> > > Gentoo systems years ago and never had any major issues.  I run
> > > both desktop and server systems with LibreSSL, based on X and
> > > Wayland. The only issues I ran into is a slight lag of the
> > > overlay behind the main tree so once in a while I had to mask a
> > > new version of some package for a week or so.
> 
> Let me just come back on the different views here:
> 
> @marcel: Exactly the same here. Smoothly running libressl on dozens
> of systems here, from embedded to ryzen servers, even on Gnome
> desktops. At least from the libressl *user's* perspective.
> 
> sam:
> 
> > TL;DR: [...libressl patches are...] just crippling functionality.
> 
> @sam: From the perspective of libressl maintainers I have had a hard
> time reading this thread ;-) to learn that even security is supposed
> to be an issue with libressl today!? Aren't these crippling patches
> sometimes even helpful (see some apache patches) to crop unreliable
> extra features? I might be wrong here. Actually I'd prefer something
> 'boring' and stable on ssl over new features...
> 
> Well, I cannot judge on the security issues in depth. From a short
> internet scan I don't see recent libressl issues but e.g. this one
> on openssl, https://www.openssl.org/news/vulnerabilities.html, only
> three weeks ago.
> 
> Anyway, my personal conclusion on security:
> 
> I've once switched to libressl because of the heartbleed issue.  If
> security is better with openssl these days, I'd of course switch
> back.

I can't say anything for sure but it is pretty clear that since
Heartbleed the level of auditing OpenSSL is receiving is much greater.
I honestly doubt that with its comparatively little user base LibreSSL
gets the same level of attention.

I don't really have the time or motivation to try to look for LibreSSL
security issues.  But if there's no CVE for such a core package for two
years, it either means that it's really good, that it's practically
dead or that nobody is actually releasing CVEs for it.

>   It might be worth having some warm explanations on the
> motivation in eselect NEWS, to help people out of the initial state
> of shock.

Of course a news item will be released once we determine the proper
course of action.

> 
> > > So from a pure user perspective, thing change would mean a risky
> > > update
> > > to systems running stable for years with no gain whatsoever.
> 
> Coming back on the technical way to switch back to openssl:
> 
> Thanks to Gentoo, isn't the switch back more or less something
> predictable like
> 
> - removing libressl USE / CURL flags
> 
> - download everything before compiling (emerge -f ...)
> 
> - removing libressl, installing openssl, maybe wget then, followed
>   by the rest?
> 
> It plead for something that actually *works* as many systems will
> need that change here.
> 

We are currently waiting for test results.  We don't want to guess
without testing for sure.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Andreas K. Huettel]

Am Dienstag, 29. Dezember 2020, 13:29:35 EET schrieb Peter Stuge:
> I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> to continuosly patch the entire world for libressel.
> 
> I'm asking to stop doing that, yet still enable the choice between
> openssl and libressl where that is possible without patches, even
> if that's only openntpd and one other package.

a) The two cannot be installed concurrently. To fix that would require even 
more hacks. 
-> all relevant ssl consumers on the user's system must be linked against the 
one selected

b) The libraries are not guaranteed to be binary compatible, so switching 
implementation requires rebuilding consumers. Especially since this is a 
security-sensitive package.
-> all relevant ssl consumers on the user's system must be *built* against the 
one selected

Which leads us to 

c) If a single package that the user wants to install is not "fixed" for one 
ssl library, it blocks that option for all packages.
-> horrible (but real and justified) emerge blockers and general hilarity ensue

I guess if you can come up with a solution that
* provides secure usage of the libraries,
* provides choice to the user, and
* doesn't lead to unupgradeable systems or unresolvable dependencies
we'd all be happier. So far we haven't found one.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 337 bytes --]

On 12/29/20 2:57 PM, m1027 wrote:
> - removing libressl, installing openssl, maybe wget then, followed
>    by the rest?
remove is sufficient b/c emerge then immediately advices a 
@preserved-rebuild - at least that's the way it works here at the 
tinderbox (in the opposite direction FWIW)

-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[m1027]

toralf:

> On 12/29/20 2:57 PM, m1027 wrote:
> > - removing libressl, installing openssl, maybe wget then, followed
> >    by the rest?
>
> remove is sufficient b/c emerge then immediately advices a 
> @preserved-rebuild - at least that's the way it works here at the 
> tinderbox (in the opposite direction FWIW)

I gave it a shot and it did not work that way here. After
uninstalling libressl and removing all according USE flags,
@preserved-rebuild always tried to pull in libressl again.

Maybe emerge -1 openssl, then emerge -auDUN @preserved-rebuild
--nodeps helps.

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Tue, 2020-12-29 at 16:12 +0100, Toralf Förster wrote:
> On 12/29/20 2:57 PM, m1027 wrote:
> > - removing libressl, installing openssl, maybe wget then, followed
> >    by the rest?
> remove is sufficient b/c emerge then immediately advices a 
> @preserved-rebuild - at least that's the way it works here at the 
> tinderbox (in the opposite direction FWIW)
> 

I'm not sure if you meant it but it reads as if you were talking about
removing the package.  This is incorrect.

You need to disable the USE flag and then --changed-use (or --newuse)
rebuild everything with the flag.  If the depgraph is clean, emerge
should happily trigger the rebuild along with automatic replacement of
dev-libs/libressl with dev-libs/openssl.

However, it's a good idea to run the same command with --fetchonly
first, to make sure that all distfiles are in place, in case wget got
broken in the process.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 903 bytes --]

On 12/29/20 7:10 PM, m1027 wrote:
> toralf:
> 
>> On 12/29/20 2:57 PM, m1027 wrote:
>>> - removing libressl, installing openssl, maybe wget then, followed
>>>     by the rest?
>> remove is sufficient b/c emerge then immediately advices a
>> @preserved-rebuild - at least that's the way it works here at the
>> tinderbox (in the opposite direction FWIW)
> I gave it a shot and it did not work that way here. After
> uninstalling libressl and removing all according USE flags,
> @preserved-rebuild always tried to pull in libressl again.
> 
> Maybe emerge -1 openssl, then emerge -auDUN @preserved-rebuild
> --nodeps helps.
> 
> 
Hhm, for OpenSSL->LibreSSL this works since years to autaomtically setup 
a new tinderbox image: 
https://github.com/toralf/tinderbox/blob/master/bin/setup_img.sh#L494

but I never tried the other way around.



-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 550 bytes --]

On 12/29/20 7:15 PM, Michał Górny wrote:
> I'm not sure if you meant it but it reads as if you were talking about
> removing the package.  This is incorrect.
> 
> You need to disable the USE flag and then --changed-use (or --newuse)
> rebuild everything with the flag.  If the depgraph is clean, emerge
> should happily trigger the rebuild along with automatic replacement of
> dev-libs/libressl with dev-libs/openssl.
You're right, the USE flags have to be adapted - forget that to mention, 
sry.

-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[John Helmert III]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On Tue, Dec 29, 2020 at 02:57:12PM +0100, m1027 wrote:
> > > On 29 Dec 2020, at 09:13, Marcel Schilling
> > > <marcel.schilling@mdc-berlin.de> wrote:
> > > 
> > > I just want to comment that I switched to LibreSSL on several
> > > Gentoo systems years ago and never had any major issues.  I run
> > > both desktop and server systems with LibreSSL, based on X and
> > > Wayland. The only issues I ran into is a slight lag of the
> > > overlay behind the main tree so once in a while I had to mask a
> > > new version of some package for a week or so.
> 
> Let me just come back on the different views here:
> 
> @marcel: Exactly the same here. Smoothly running libressl on dozens
> of systems here, from embedded to ryzen servers, even on Gnome
> desktops. At least from the libressl *user's* perspective.
> 
> sam:
> 
> > TL;DR: [...libressl patches are...] just crippling functionality.
> 
> @sam: From the perspective of libressl maintainers I have had a hard
> time reading this thread ;-) to learn that even security is supposed
> to be an issue with libressl today!? Aren't these crippling patches
> sometimes even helpful (see some apache patches) to crop unreliable
> extra features? I might be wrong here. Actually I'd prefer something
> 'boring' and stable on ssl over new features...
> 
> Well, I cannot judge on the security issues in depth. From a short
> internet scan I don't see recent libressl issues but e.g. this one
> on openssl, https://www.openssl.org/news/vulnerabilities.html, only
> three weeks ago.

That particular vulnerability (CVE-2020-1971) affects both libressl and openssl, and
Gentoo has bugs for both.

https://bugs.gentoo.org/759079
https://bugs.gentoo.org/759175

The openssl bug has been fixed, but the libressl bug remains open,
despite both being opened within two days of each (and now existing
for several weeks).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Paul B. Henson]

On Tue, Dec 29, 2020 at 01:24:33PM +0100, Michał Górny wrote:

> As noted in another fork of this thread, libtls is now provided
> by dev-libs/libretls which works against OpenSSL.

The latest version of libressl also supports linking libtls statically
against libssl and libcrypto, allowing it to be used alongside openssl
while still using libressl guts. Of course, then you'd end up with
basically two ssl implementations loaded, so dunno it's very efficient,
but just to point it out :).

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Andreas K. Huettel wrote:
> > I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> > to continuosly patch the entire world for libressel.
> > 
> > I'm asking to stop doing that, yet still enable the choice between
> > openssl and libressl where that is possible without patches, even
> > if that's only openntpd and one other package.
> 
> a) The two cannot be installed concurrently. To fix that would require even 
> more hacks.

As we've discussed in another part of the thread, that's not really true.
Both can for sure be installed, just not in the same place and/or
with same names.


> -> all relevant ssl consumers on the user's system must be linked against
> the one selected

Also not the case. Considering the two installed in different paths
with same names it's still easy for consumers to use one or the other
with -rpath at link time.


I do agree that the two are not always 1:1 replacements for each other.
If they are API incompatible somewhere then for sure not.

I think many mails in this thread suffer from some tunnel vision, expecting
that a libressl ebuild in the tree must continue to work exactly like the
openssl ebuild - I'm saying to stop that but do keep a libressl ebuild.


> b) The libraries are not guaranteed to be binary compatible, so switching 
> implementation requires rebuilding consumers.

We can only consider ABI compatibility if we have API compatibility,
which might not even be a given.


> c) If a single package that the user wants to install is not "fixed" for
> one ssl library, it blocks that option for all packages.

Please think of a libressl ebuild in a new way.


> I guess if you can come up with a solution that
> * provides secure usage of the libraries,
> * provides choice to the user, and
> * doesn't lead to unupgradeable systems or unresolvable dependencies
> we'd all be happier. So far we haven't found one.

Right! I think letting a libressl ebuild install only libtls could be a
good start, because it provides a stable situation, without risking
conflicts. Would you agree?


Thanks

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Hanno Böck]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

The bindist flags in openssl + openssh were for elliptic curve support,
as people were concerned about patents.
I'm almost certain this affects libressl just the same way, probably
just noone ever bothered to care.

The bindist flags should probably be reviewed and likely removed.
According to Wikipedia [1] the last possibly relevant ECC patent is
valid until 2020. So 2 more days. There shouldn't be any patent
concerns about ECC any more.


[1] https://en.wikipedia.org/wiki/ECC_patents

-- 
Hanno Böck
https://hboeck.de/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Matt Turner]

On Tue, Dec 29, 2020 at 2:47 PM Peter Stuge <peter@stuge.se> wrote:
>
> Andreas K. Huettel wrote:
> > > I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> > > to continuosly patch the entire world for libressel.
> > >
> > > I'm asking to stop doing that, yet still enable the choice between
> > > openssl and libressl where that is possible without patches, even
> > > if that's only openntpd and one other package.
> >
> > a) The two cannot be installed concurrently. To fix that would require even
> > more hacks.
>
> As we've discussed in another part of the thread, that's not really true.
> Both can for sure be installed, just not in the same place and/or
> with same names.
>
>
> > -> all relevant ssl consumers on the user's system must be linked against
> > the one selected
>
> Also not the case. Considering the two installed in different paths
> with same names it's still easy for consumers to use one or the other
> with -rpath at link time.
>
>
> I do agree that the two are not always 1:1 replacements for each other.
> If they are API incompatible somewhere then for sure not.
>
> I think many mails in this thread suffer from some tunnel vision, expecting
> that a libressl ebuild in the tree must continue to work exactly like the
> openssl ebuild - I'm saying to stop that but do keep a libressl ebuild.

If they suffer from tunnel vision, it's because the intersection of
"people who care about libressl" and "people who have patches in
gentoo.git" is the empty set.

I think we all understand your points: libressl could be kept in-tree
and allow people to play with it. Unfortunately that requires much
more work than removing it, and I haven't seen evidence that you're
prepared to contribute to the required effort.

I don't think you're going to convince a bunch of people with little
interest in libressl per se to continue allowing the extra burden
unless you do the work that's needed to keep it in-tree (e.g., to
allow it to be installed beside openssl). They're not interested.

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Stefan Strogin]

Hi,

On 28/12/2020 11:56, Michał Górny wrote:
> Hello, developers and Gentoo LibreSSL team.
> 
> TL;DR: is there really a point in continuing the never-ending always-
> regressing struggle towards supporting LibreSSL in Gentoo?
> 

I don't agree.

I have asked ~20 users who made any contributions (like bug reports or patches)
recently, and almost all of them think that having a choice between OpenSSL
and LibreSSL adds value to Gentoo. Some still trust LibreSSL more than OpenSSL
because of its sins of the past. Although I can see that OpenSSL made a good
progress in the latest several years. Anyway LibreSSL serves well to some
number of users, and switching back to OpenSSL can be troublesome (think if you
had dozens of servers running LibreSSL).

LibreSSL support in Gentoo is not critical for me. But it doesn't take too
much effort. I think the cost-benefit ratio is good enough for keeping it.

Last but not least, the LibreSSL itself is well, alive and actively developed.
People might want to use it. I see no good reasons not to support it,
other than lack of time, will and effort.
I really think that ability to choose (even between things that do not have
great advantage over each other) - is a value in itself.

> 
> The vast majority of software is not tested against LibreSSL.  While
> patches are usually trivial and we have people that submit them,
> I find many of them short-sighted.  Just look at [1].  Sure, it fixes
> the build today but it disabled the feature for all foreseeable future.
> How likely is it that somebody will submit another patch reenabling it
> with a future LibreSSL version?

The likelihood is greater than zero:
https://github.com/lighttpd/lighttpd1.4/commit/57f450f1992fc4e28cf85969eeebccb240df4303
https://github.com/gentoo-mirror/gentoo/commit/c7792db235647a6441b315528997b40ba2beeaaa
https://github.com/Yubico/yubico-piv-tool/commit/3bcd36bbdbbdc86d06cc53df7e3b7c30d12cd33e
etc...

That was why I disagree.

But I'll acquiesce in the decision to remove LibreSSL, because the number of
developers that actually work on LibreSSL support is about 1.5. And unfortunately
I don't have much time and effort for Gentoo currently, because of the main job
and other life (I hope it will change soon though).

I would be happier if some other developers were able and willing to participate
actively in the LibreSSL project. But if not, not.
Just make the transition as painless as possible.

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Matt Turner wrote:
> > I think many mails in this thread suffer from some tunnel vision, expecting
> > that a libressl ebuild in the tree must continue to work exactly like the
> > openssl ebuild - I'm saying to stop that but do keep a libressl ebuild.

To clarify, by "stop that" I mean "stop efforts to make libressl a
drop-in replacement".


> If they suffer from tunnel vision, it's because the intersection of
> "people who care about libressl" and "people who have patches in
> gentoo.git" is the empty set.

Tunnel vision refered not to people but what a libressl ebuild delivers,
which you seems to have turned into an ad hominem against me?

Who will do actual work is a separate question, of course if noone wants
to then nothing matters, but it seems that some people /do/ care about
libressl; I suppose the 61 patches mgorny found were committed by someone.

If you were somehow trying to belittle /me/ then it's certainly true that
I'm not a Gentoo developer, but there are some patches by me in gentoo.git.


> I think we all understand your points: libressl could be kept in-tree
> and allow people to play with it. Unfortunately that requires much
> more work than removing it, and I haven't seen evidence that you're
> prepared to contribute to the required effort.
> 
> I don't think you're going to convince a bunch of people with little
> interest in libressl per se to continue allowing the extra burden
> unless you do the work that's needed to keep it in-tree (e.g., to
> allow it to be installed beside openssl).

You seem to not understand my point at all.

As I've written I (like others) argue against "continue allowing extra burden"
and I've suggested and offered to help with one approach to keep a libressl
ebuild in the tree.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Wed, 2020-12-30 at 01:00 +0300, Stefan Strogin wrote:
> I would be happier if some other developers were able and willing to
> participate
> actively in the LibreSSL project. But if not, not.
> Just make the transition as painless as possible.

But why would they do that?  What I'm really missing in all the replies
is a single reason why LibreSSL would be better for anyone.  Not 'it's
an alternative', not 'I don't trust' but a real proper, verifiable
argument 'LibreSSL is better in this regard'.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > I would be happier if some other developers were able and willing to
> > participate actively in the LibreSSL project.
> 
> But why would they do that?  What I'm really missing in all the replies
> is a single reason why LibreSSL would be better for anyone.

Maybe because it is so well-known that monoculture is harmful per se,
which is why the commitment to choice in Gentoo is very valuable.

Further, LibreSSL comes out of the OpenBSD project, which has a good
reputation on code quality.


> a real proper, verifiable argument 'LibreSSL is better in this regard'.

Choice is about enabling people to decide for themselves.

Choice is /not/ about forcing people to formally prove utility to yourself.


I acknowledge that what I suggest isn't immediately enabling libressl as
a choice either, but it is at least far less destructive than masking and
removal.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[David Seifert]

On Tue, 2020-12-29 at 22:41 +0000, Peter Stuge wrote:
> Michał Górny wrote:
> > > I would be happier if some other developers were able and willing
> > > to
> > > participate actively in the LibreSSL project.
> > 
> > But why would they do that?  What I'm really missing in all the
> > replies
> > is a single reason why LibreSSL would be better for anyone.
> 
> Maybe because it is so well-known that monoculture is harmful per se,
> which is why the commitment to choice in Gentoo is very valuable.
> 
> Further, LibreSSL comes out of the OpenBSD project, which has a good
> reputation on code quality.

Like strong-arming 99% of the users of OpenSSH because they were
unwilling to port to the OpenSSL 1.1 API, fully well knowing that most
of the OpenSSH consuming world doesn't actually use libressl? How is
explicitly tying OpenSSH to libressl not a form of monoculture?

If you want to provide an alternative, you have to subsume the API, not
make it superficially compatible, only to find out that the you need to
mask out a ton of stuff with macros. Case in point: Have you tried using
the official libjpeg package instead of libjpeg-turbo? Go ahead, give it
a try. "Monoculture"s are mostly a coincidence, not some sinister
conspiracy. Implementation-diversity-but-API-compatibility is mostly a
pipe dream, as libav, imagemagick, libjpeg have shown.

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

David Seifert wrote:
> > Maybe because it is so well-known that monoculture is harmful per se,
> > which is why the commitment to choice in Gentoo is very valuable.
> > 
> > Further, LibreSSL comes out of the OpenBSD project, which has a good
> > reputation on code quality.
> 
> Like strong-arming 99% of the users of OpenSSH because they were
> unwilling to port to the OpenSSL 1.1 API, fully well knowing that most
> of the OpenSSH consuming world doesn't actually use libressl? How is
> explicitly tying OpenSSH to libressl not a form of monoculture?

Now we're properly off-topic :) but considering that OpenSSH is developed
for OpenBSD and that openssh-portable is merely provided as a service to
other systems it's easy to understand why OpenSSH (remember, part of OpenBSD)
uses the libressl API for crypto, and why the -portable team is not so keen
on maintaining patches for other crypto providers. Another example is systemd
binding tightly to Linux. In both cases it's understandable, but also quite
unfortunate; better portability would be better.


> Case in point: Have you tried using the official libjpeg package instead
> of libjpeg-turbo? Go ahead, give it a try.

I'll take a look. I chose libjpeg-turbo for a project because it
cross-compiled better.


> "Monoculture"s are mostly a coincidence, not some sinister conspiracy.

I don't claim conspiracy, I just say that it's healthy to avoid them.


> Implementation-diversity-but-API-compatibility is mostly a
> pipe dream, as libav, imagemagick, libjpeg have shown.

I've been fortunate to have a different experience with other codebases.

It's completely possible, but takes (extra!) effort, meaning you have
to really want it. If there is some rivalry then it's also quite easy
to sabotage your colleagues.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Tue, 2020-12-29 at 22:41 +0000, Peter Stuge wrote:
> Michał Górny wrote:
> > > I would be happier if some other developers were able and willing
> > > to
> > > participate actively in the LibreSSL project.
> > 
> > But why would they do that?  What I'm really missing in all the
> > replies
> > is a single reason why LibreSSL would be better for anyone.
> 
> Maybe because it is so well-known that monoculture is harmful per se,
> which is why the commitment to choice in Gentoo is very valuable.

How is that an argument for LibreSSL?  If I create another fork of
OpenSSL and replace LibreSSL with it, your argument still stands.

> Further, LibreSSL comes out of the OpenBSD project, which has a good
> reputation on code quality.

I could buy that if it actually said anything about LibreSSL code
quality.  So far you're guessing that it might or might not, especially
given it is forked from an apparently 'inferior quality' code.

However, I do have serious doubts about LibreSSL quality given that:

1. Non-OpenBSD systems are not first class citizens, as you yourself
pointed out.

2. The library is an intrusive replacement for OpenSSL.  In the default
setup, it is neither co-installable with OpenSSL, nor a drop-in
replacement.

3. The upstream declares OpenSSL version constants pretty randomly,
without actually matching OpenSSL API.

4. The upstream has actively tried to force people into using their
product by tight coupling and forced incompatibility.

5. Apparently nobody is issuing CVEs for LibreSSL while
the vulnerabilities clearly do happen.

> > a real proper, verifiable argument 'LibreSSL is better in this
> > regard'.
> 
> Choice is about enabling people to decide for themselves.

Choice for the sake of choice is meaningless.  I can create 10 OpenSSL
forks right now and tell people to choose between them.  However, it is
meaningless unless users are actually provided good and useful
information on what particular choices represent.

So far nobody has been able to find a strong argument for choosing
LibreSSL.  There are strong arguments for using OpenSSL instead.
So what do users exactly gain from this choice?  The thrill
of adventure?  The ability to discover that they've made a bad choice
eventually and revert to OpenSSL?

Let's say you have food product A.  Then a new alternative B appears. 
Surely, some people will try it.  But if it turns out to be bad, it
will eventually unprofitable and disappear.  Sure, a few people will
complain that B is no longer there because they liked it better.  But
they wouldn't pay extra (much extra) to keep it.

OpenSSL/LibreSSL is the same.  Maybe LibreSSL had promised a better
taste in the beginning but today 9 out of 10 consumers say OpenSSL
tastes much better.  The only difference is that you don't have to pay
for it (but we do!), so you think that it's free.


-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

We could clearly discuss forever, but since you refuse to engage with
my constructive proposition and my ask for feedback there's no point,
is there? It's super sad that you behave like that in Gentoo.


Michał Górny wrote:
> Choice for the sake of choice is meaningless.

Far from it.


> So far nobody has been able to find a strong argument for choosing
> LibreSSL.  There are strong arguments for using OpenSSL instead.

That's like your opinion, man. :)


> Maybe LibreSSL had promised a better taste in the beginning but today
> 9 out of 10 consumers say OpenSSL tastes much better.

It's usually harmful to optimize for popularity; smoking isn't a good
idea even if everyone in school does it.


> The only difference is that you don't have to pay
> for it (but we do!), so you think that it's free.

Please stop playing the victim and engage with my proposal instead.

I'd appreciate feedback from everyone.


Thanks a lot

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Marcel Schilling]

On Tue, Dec 29, 2020 at 11:31:32PM +0100, Michał Górny wrote:
> What I'm really missing in all the replies is a single reason why
> LibreSSL would be better for anyone.  Not 'it's an alternative', not
> 'I don't trust' but a real proper, verifiable argument 'LibreSSL is
> better in this regard'.

I guess that is due the fact that you dismiss arguments that are valid
reasons for others (incl. me) but apparently not sufficient for you,
like my situation where 'It works on all my systems, and switching would
mean work for me and at least a risk of downtimes'.
I understand that if security of OpenSSL is much better than LibreSSL (I
have also not seen 'proof' of this, just 'more users mean better
security per se', so I guess I should switch from Gentoo to Ubuntu for
my desktops and CentOS for my servers if I care about security), I
should switch back, but for me, not having to touch working systems is a
valid reason to keep the system around.
Since I can't contribute the work needed to keep it around, I'll have to
live with the consequences of whatever the devs decide. And I will. Just
don't expect me to pretend like you are doing me a favour. ;-)

Best,
Marcel

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Wed, 2020-12-30 at 09:08 +0100, Marcel Schilling wrote:
> On Tue, Dec 29, 2020 at 11:31:32PM +0100, Michał Górny wrote:
> > What I'm really missing in all the replies is a single reason why
> > LibreSSL would be better for anyone.  Not 'it's an alternative', not
> > 'I don't trust' but a real proper, verifiable argument 'LibreSSL is
> > better in this regard'.
> 
> I guess that is due the fact that you dismiss arguments that are valid
> reasons for others (incl. me) but apparently not sufficient for you,
> like my situation where 'It works on all my systems, and switching would
> mean work for me and at least a risk of downtimes'.

I don't dismiss that.  If I had, I wouldn't be bothering with the whole
discussion and just kill it.  I just draw a different conclusion than
you do.

Having systems that do work with LibreSSL today doesn't guarantee
the same for the foreseeable future.  If anything, I prefer to ask
the existing users to perform a conscious migration today, than wait
till things become really unusable and more users are forced to migrate
their systems without realizing the risks.

It's all nice to say that LibreSSL will be usable in the near future
but that's just plain lying.  We're between LibreSSL upstream that
explicitly rejects any idea of interoperability with OpenSSL, and other
upstreams that plain reject the idea of bending their software to work
with LibreSSL.

I'm sorry to say but in my opinion LibreSSL's team attitude is to blame
in the first place here.  If someone forks something, deliberately
breaks compatibility and then tries everyone to use his work, what else
would you expect to happen?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[m1027]

mgorny:

> On Tue, 2020-12-29 at 16:12 +0100, Toralf Förster wrote:
> > On 12/29/20 2:57 PM, m1027 wrote:
> > > - removing libressl, installing openssl, maybe wget then, followed
> > >    by the rest?
> > remove is sufficient b/c emerge then immediately advices a 
> > @preserved-rebuild - at least that's the way it works here at the 
> > tinderbox (in the opposite direction FWIW)
> > 
> 
> I'm not sure if you meant it but it reads as if you were talking about
> removing the package.  This is incorrect.
> 
> You need to disable the USE flag and then --changed-use (or --newuse)
> rebuild everything with the flag.  If the depgraph is clean, emerge
> should happily trigger the rebuild along with automatic replacement of
> dev-libs/libressl with dev-libs/openssl.
> 
> However, it's a good idea to run the same command with --fetchonly
> first, to make sure that all distfiles are in place, in case wget got
> broken in the process.

It might not be the place to discuss emerge dependency details here,
take it as some initial feedback on the transition from libressl to
openssl.

The general way to go seems indeed:

- remove libressl from USE flags, also adjusting curl_ssl
- initial emerge ... --fetchonly: to my surprise not always required
- emerge -autDUN @world
- finally the usual @preserved-rebuild
- On some systems another @world update revealed again a lot
- This also worked over ssh

The systems I tried so far

- 2x Gnome desktop systems, close to the USE defaults, went smoothly
- 1x Raspberry Pi over ssh: still working, ;-) okay so far
- 1x Developer system with some smaller issues

The issues I had:

- hostapd: when with +internal-tls, some build issue with
  libtommath; when with -internal-tls it required openssl -bindist;
  I did not investigate, just uninstalled hostapd yet

- openssl+bind+openssh: conflict triggered to do +/-bindist for
  openssl; solution was -bindist everywhere (see other posts on
  bindist already)

- old android-tools-6.0.1_p79: build issue mentioning ssl; not
  ivestigated further, just uninstalled

Thanks

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Michał Górny]

On Wed, 2020-12-30 at 11:41 +0100, m1027 wrote:
> mgorny:
> 
> > On Tue, 2020-12-29 at 16:12 +0100, Toralf Förster wrote:
> > > On 12/29/20 2:57 PM, m1027 wrote:
> > > > - removing libressl, installing openssl, maybe wget then, followed
> > > >    by the rest?
> > > remove is sufficient b/c emerge then immediately advices a 
> > > @preserved-rebuild - at least that's the way it works here at the 
> > > tinderbox (in the opposite direction FWIW)
> > > 
> > 
> > I'm not sure if you meant it but it reads as if you were talking about
> > removing the package.  This is incorrect.
> > 
> > You need to disable the USE flag and then --changed-use (or --newuse)
> > rebuild everything with the flag.  If the depgraph is clean, emerge
> > should happily trigger the rebuild along with automatic replacement of
> > dev-libs/libressl with dev-libs/openssl.
> > 
> > However, it's a good idea to run the same command with --fetchonly
> > first, to make sure that all distfiles are in place, in case wget got
> > broken in the process.
> 
> It might not be the place to discuss emerge dependency details here,
> take it as some initial feedback on the transition from libressl to
> openssl.
> 
> The general way to go seems indeed:
> 
> - remove libressl from USE flags, also adjusting curl_ssl
> - initial emerge ... --fetchonly: to my surprise not always required
> - emerge -autDUN @world
> - finally the usual @preserved-rebuild

I'm surprised this is necessary.  -N should have rebuilt everything,
unless:

1) you had some packages installed that are no longer in @world
depgraph, or

2) packages have automagic dependencies.

If you see things like this, it's worth investigating and reporting
bugs if it's 2.

> - On some systems another @world update revealed again a lot
> - This also worked over ssh
> 
> The systems I tried so far
> 
> - 2x Gnome desktop systems, close to the USE defaults, went smoothly
> - 1x Raspberry Pi over ssh: still working, ;-) okay so far
> - 1x Developer system with some smaller issues
> 
> The issues I had:
> 
> - hostapd: when with +internal-tls, some build issue with
>   libtommath; when with -internal-tls it required openssl -bindist;
>   I did not investigate, just uninstalled hostapd yet
> 
> - openssl+bind+openssh: conflict triggered to do +/-bindist for
>   openssl; solution was -bindist everywhere (see other posts on
>   bindist already)

As mentioned somewhere else in this thread, USE=bindist is going to be
revisited in the next few days, since some significant patents expire
by 2021.


-- 
Best regards,
Michał Górny

[gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Michał Górny]

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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Andreas K. Huettel]

> > a) The two cannot be installed concurrently. To fix that would require
> > even
> > more hacks.
> 
> As we've discussed in another part of the thread, that's not really true.
> Both can for sure be installed, just not in the same place and/or
> with same names.

Exactly that is what would require even more hacks. Given how many different 
and more or less hackish build systems exist in the Gentoo tree, this is just 
not feasible.

> > -> all relevant ssl consumers on the user's system must be linked against
> > the one selected
> 
> Also not the case. Considering the two installed in different paths
> with same names it's still easy for consumers to use one or the other
> with -rpath at link time.

Dito...

Please remember, the point is to keep this somewhat maintainable.

> > c) If a single package that the user wants to install is not "fixed" for
> > one ssl library, it blocks that option for all packages.
> 
> Please think of a libressl ebuild in a new way.

Well, if it just drops the library somewhere where nothing can use it... that 
can for sure be done, but also does not really help anyone.

> > I guess if you can come up with a solution that
> > * provides secure usage of the libraries,
> > * provides choice to the user, and
> > * doesn't lead to unupgradeable systems or unresolvable dependencies
> > we'd all be happier. So far we haven't found one.
> 
> Right! I think letting a libressl ebuild install only libtls could be a
> good start, because it provides a stable situation, without risking
> conflicts. Would you agree?

No idea to be honest, and not much opinion on this.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Anthony G. Basile]

On 12/29/20 5:41 PM, Peter Stuge wrote:
> Michał Górny wrote:
>>> I would be happier if some other developers were able and willing to
>>> participate actively in the LibreSSL project.
>>
>> But why would they do that?  What I'm really missing in all the replies
>> is a single reason why LibreSSL would be better for anyone.
> 
> Maybe because it is so well-known that monoculture is harmful per se,
> which is why the commitment to choice in Gentoo is very valuable.
> 
> Further, LibreSSL comes out of the OpenBSD project, which has a good
> reputation on code quality.
> 

I am sympathetic to not degrading into a monoculture.  If I would
characterize my contribution to Gentoo over the years it would be
"alt-everything".  The reason being that competition between
alternatives is a good thing and time will tell which way is best.

But <- here's the "but"

At some point a particular path may have to be dropped because it just
doesn't provide any clear advantages.  There was nothing wrong with
adding libressl as an alternative in 2014 since it had promise.  And
now, years later, I see nothing wrong with removing it.  It hasn't
delivered.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Anthony G. Basile]

On 12/29/20 6:06 PM, David Seifert wrote:
> 
> If you want to provide an alternative, you have to subsume the API, not
> make it superficially compatible, only to find out that the you need to
> mask out a ton of stuff with macros. 

Agreed.  If libressl hadn't failed on this point, we would not be having
this conversation.  They promised it would be API compatible and it
started that way, but not anymore.  This became annoying even to me with
my other packages like stunnel, where with every bump I had to create a
new patch with macros based on versions.  This is not something we want
to saddle the rest of Gentoo with.  Nor do we want to burden upstream
teams to have to follow libressl's insanity.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Peter Stuge]

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

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Michał Górny]

On Wed, 2020-12-30 at 15:02 +0000, 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?

[Peter Stuge]

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?

[Mike Gilbert]

On Wed, Dec 30, 2020 at 9:50 PM Peter Stuge <peter@stuge.se> 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?

[David Seifert]

On Thu, 2020-12-31 at 02:50 +0000, 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?

[Michał Górny]

On Thu, 2020-12-31 at 02:50 +0000, 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] Discontinuing LibreSSL support?

[Thomas Mueller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Excerpt from Michał Górny and previous post:

> > Further, LibreSSL comes out of the OpenBSD project, which has a good
> > reputation on code quality.

> I could buy that if it actually said anything about LibreSSL code
> quality.  So far you're guessing that it might or might not, especially
> given it is forked from an apparently 'inferior quality' code.

> However, I do have serious doubts about LibreSSL quality given that:

> 1. Non-OpenBSD systems are not first class citizens, as you yourself
> pointed out.

> 2. The library is an intrusive replacement for OpenSSL.  In the default
> setup, it is neither co-installable with OpenSSL, nor a drop-in
> replacement.

> 3. The upstream declares OpenSSL version constants pretty randomly,
> without actually matching OpenSSL API.

> 4. The upstream has actively tried to force people into using their
> product by tight coupling and forced incompatibility.

> 5. Apparently nobody is issuing CVEs for LibreSSL while
> the vulnerabilities clearly do happen.

My limited experience with OpenBSD does not give credence to their code quality.

Latest experience was from liveusb-openbsd.sourceforge.net.

I was able to download the image and write to 64 GB USB stick.

I managed to get it to boot, but couldn't find my way around.

It couldn't read my GPT-partitioned hard drive, and I was not about to take big risks regarding my data.

OpenBSD fdisk is quite primitive compared to NetBSD (gpt), FreeBSD (gpart), Linux (gdisk: also available for FreeBSD, Windows and macOS).

OpenBSD seems to have dubious compatibility with NetBSD, FreeBSD and Linux software packages, and is not good at peaceful coexistence with NetBSD, FreeBSD, Linux and probably other OSes on the hard drive.

I looked in NetBSD pkgsrc, FreeBSD ports, Gentoo portage, and Void Linux packages, and libressl was there, which is not to say how compatible it is or how much patching is needed.

Tom

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Peter Stuge]

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?

[Jaco Kroon]

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
>

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Peter Stuge]

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


Kind regards

//Peter

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Alessandro Barbieri]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

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

>

[-- Attachment #2: Type: text/html, Size: 1282 bytes --]

Re: [gentoo-dev] Static libraries

[Peter Stuge]

Alessandro Barbieri wrote:
> > 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.

I know, and I couldn't disagree more with that effort.


> > but I think that's far better than removing libressl.
> 
> No, it's not better, it's more work for the security team.

The security team isn't be responsible for what people do.

Flip side: The security team is also not entitled to decide what people
can and can not do.

Security is a policy and technology generally needs to avoid forcing
policy onto humans, but enable human decisions. You can tell that I
value choice.

It's certainly a good default to use shared libraries, but it's no good at
all to hamper legitimate functionality under a guise of security. That's a
far too common and really diseased pattern throughout society, and it makes
me sad that it proliferates also in Gentoo.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Patrick McLean]

On Tue, 29 Dec 2020 23:34:36 +0000
Peter Stuge <peter@stuge.se> wrote:

> David Seifert wrote:
> > > Maybe because it is so well-known that monoculture is harmful per se,
> > > which is why the commitment to choice in Gentoo is very valuable.
> > > 
> > > Further, LibreSSL comes out of the OpenBSD project, which has a good
> > > reputation on code quality.  
> > 
> > Like strong-arming 99% of the users of OpenSSH because they were
> > unwilling to port to the OpenSSL 1.1 API, fully well knowing that most
> > of the OpenSSH consuming world doesn't actually use libressl? How is
> > explicitly tying OpenSSH to libressl not a form of monoculture?  
> 
> Now we're properly off-topic :) but considering that OpenSSH is developed
> for OpenBSD and that openssh-portable is merely provided as a service to
> other systems it's easy to understand why OpenSSH (remember, part of OpenBSD)
> uses the libressl API for crypto, and why the -portable team is not so keen
> on maintaining patches for other crypto providers. Another example is systemd
> binding tightly to Linux. In both cases it's understandable, but also quite
> unfortunate; better portability would be better.

I don't have any strong opinions on either side of this argument, I
have 1 machine on LibreSSL that I would need to switch, but that is
not really a major issue for me.

As the person who has been doing a large percentage of the OpenSSH
ebuild maintenance for a couple of years now I feel I should
mention that while it was the case that OpenSSH would not work with
OpenSSL 1.1+ without a (rather large) patch in the past, that has not
been the case for some time now. Modern OpenSSH versions work fine with
modern OpenSSL versions.