Re: [RFC] Switching to OpenSSL 3?

[Mike Gilbert <floppym@xxxxxxxxxx>]

On Tue, May 17, 2022 at 2:53 PM Luca Boccassi <bluca@xxxxxxxxxx> wrote:
>
> On Sat, 9 Oct 2021 at 19:11, Luca Boccassi <bluca@xxxxxxxxxx> wrote:
> >
> > On Wed, 2021-09-29 at 18:11 +0100, Luca Boccassi wrote:
> > > On Wed, 2021-09-15 at 16:06 +0100, Luca Boccassi wrote:
> > > > On Tue, 2021-09-14 at 13:36 +0200, Lennart Poettering wrote:
> > > > > Heya!
> > > > >
> > > > > Some of the systemd developers have been discussing switching
> > > > > systemd's crypto libraries to be exclusively OpenSSL 3.0, and
> > > > > drop
> > > > > support for older OpenSSL versions, as well as any
> > > > > GNUTLS/libgcrypt
> > > > > support. As you might have noticed OpenSSL 3.0 has been released
> > > > > recently, and for the first time resolves the GPL2 license
> > > > > incompatibility mess comprehensively, which opens this door to
> > > > > us.
> > > > >
> > > > > I personally care a lot about reducing the combinatorial
> > > > > explosion of
> > > > > deps a bit, and keeping our tree as maintainable as we can, with
> > > > > a
> > > > > single implementation of everything, not multiple, and no
> > > > > abstraction
> > > > > layers and such, and thus removing any compat kludges for other
> > > > > libraries or other library versions.
> > > > >
> > > > > Now, before we make a decision on this, I'd like to collect
> > > > > feedback
> > > > > on such a move. I know that there are some people who backpart
> > > > > new
> > > > > systemd onto old distros. How big would the pain be require
> > > > > porting
> > > > > OpenSSL 3, too, at the same time?
> > > > >
> > > > > (What's not up for discussion: for new additions to systemd we'll
> > > > > do
> > > > > only OpenSSL, and won't accept anything else. My question is
> > > > > really
> > > > > just about the stuff we aleady have, where we currently support
> > > > > GNUTLS/libcgrypt.).
> > > > >
> > > > > Anyway, I'd be interested in your thoughts about this. i.e. hear
> > > > > multiple takes, opinions, from differently people and positions?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Lennart
> > > >
> > > > To summarize in public what we discussed elsewhere:
> > > >
> > > > - OpenSSL 3 is licensed under Apache2 which is compatible with
> > > > GPLv3
> > > > but believed by many to be incompatible with GPLv2
> > > > - systemd is mostly (L)GPLv2+, with no specific OpenSSL exception
> > > > clauses
> > > > - distributors of the built and linked binaries can safely and
> > > > without
> > > > any reasonable doubt get over the perceived incompatibility by
> > > > declaring that the  GPLv2+ binaries linked to OpenSSL are
> > > > distributed
> > > > under GPLv3
> > > >
> > > > The issue of course is with the "mostly" keyword. There are many
> > > > compat-headers backported from Linux UAPI headers, but they are
> > > > covered
> > > > by the Linux syscall-note exception so they explicitly do not
> > > > affect
> > > > the license of the binaries built with them.
> > > > There are however three GPLv2-only headers with no exceptions
> > > > currently
> > > > included in all builds:
> > > >
> > > > - src/basic/ioprio.h which is in the process of being removed via
> > > > https://github.com/systemd/systemd/pull/20736
> > > > - src/basic/linux/loadavg.h which is copied from
> > > > https://github.com/torvalds/linux/blob/master/include/linux/sched/loadavg.h
> > > > - src/shared/linux/bpf_insn.h which is copied from
> > > > https://github.com/torvalds/linux/blob/master/samples/bpf/bpf_insn.h
> > > >
> > > > The third one to me seems the most problematic one, as it's fairly
> > > > complex and thus is unlikely to be perceived universally as exempt
> > > > from
> > > > copyright. It is very annoying as it is clearly a "sample" source
> > > > file,
> > > > which usually is intended to be reused liberally, and originally it
> > > > was
> > > > without a license and was given GPLv2-only when the big SPDX
> > > > refactor
> > > > happened. There are 5 companies or so holding copyright on that
> > > > file,
> > > > so perhaps a quick avenue would be to seek their permission to dual
> > > > license it? BPF support in systemd is of course optional, so it
> > > > could
> > > > instead be disabled everywhere so that the header is excluded at
> > > > build
> > > > time, but it would be quite unfortunate
> > >
> > > Status update: all these issues have been solved. The first two
> > > headers
> > > have been removed, and the third one has been dual-licensed upstream.
> > >
> > > https://github.com/systemd/systemd/pull/20736
> > > https://github.com/systemd/systemd/pull/20839
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=d75fe9cb1dd062684c9fb8a4581738170365dc06
> > >
> > > Therefore, we can say with certainty and no doubt whatsoever that
> > > systemd binaries can be distributed under (L)GPL-2-or-later and thus
> > > be
> > > compatible with Apache2, enabling linking with OpenSSL 3.
> > >
> > > The current plan is to avoid linking libsystemd.so to OpenSSL, so
> > > that
> > > the license of this library as distributed is not affected.
> >
> > Another update: libsystemd.so will no longer link to OpenSSL, even when
> > it's used by other parts of the project. This should remove any
> > remaining doubt on what shipping with OpenSSL 3.0 means for users, and
> > make the situation super crystal clear.
> >
> > Unrelated to licensing, for the next step we will also try to remove
> > the dependency on libgcrypt, simply to make the installation footprint
> > of libsystemd.so smaller.
>
> Another update: OpenSSL 3 is now in Debian unstable, going through the
> motions. What's the status in Gentoo?

It's being tested by a small subset of users at the moment; there are
several high-profile reverse dependencies that are broken with OpenSSL
3.0.

Here's our tracker bug: https://bugs.gentoo.org/797325

Some of these might be fixed upstream, and just require a version bump
or backport in Gentoo.