[systemd-devel] [RFC] Switching to OpenSSL 3?

[Luca Boccassi]

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.

This covers the situation regarding executables (and internal details).
The point was raised that we also have a public shared library,
libsystemd.so, which is currently licensed as LGPLv2+. This links to
libgcrypt.so, which is slated for replacement by OpenSSL. But doing so
would mean that the shared library would then have to be distributed
under LGPLv3+, which would be a massive headache for many many reasons
that I am not going to get into here, as programs link to it directly.

libgcrypt is used by two source files in libsystemd:

src/libsystemd/sd-journal/fsprg.c
src/libsystemd/sd-journal/journal-authenticate.c

The first uses it to calculate HMACs, the second to get high quality
random numbers.

There would seem to be 3 solutions to keep libsystemd.so distributed
under LGPLv2:

1) Keep using libgcrypt only in those two files and remove it
everywhere else
2) Find a third GPLv2-compatible solution in place of libgcrypt for
those two files
3) Deprecate and remove those APIs

We generally do not break backward compatibility in the public library
for good reasons so the third one is out, and in the short term the
second one is going to be quite difficult. So perhaps the best way
forward is at least for the initial switch to keep libgcrypt in place
exclusively for libsystemd.so, and then eventually remove it without
adding libcrypto in its place?

It has been pointed out that some HMAC primitives might be available
under: https://github.com/dot-asm/cryptogams

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210915/fd98a8a7/attachment.sig>