Re: [RFC] Switching to OpenSSL 3?

[Luca Boccassi <bluca@xxxxxxxxxx>]

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?

Upstream-wise, as the next step we'd like to drop support for
resolved+gnutls, and support it only with openssl. Is there anybody
left that relies on resolved+gnutls and cannot use openssl? This would
happen after the next release, ie in the v252 timeframe.

Next step after this is finding an alternative for libmicrohttpd,
which will be the last usage of gnutls, to be finally able to drop it.

Kind regards,
Luca Boccassi