Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Tue, May 17, 2022 at 2:53 PM Luca Boccassi wrote: > > On Sat, 9 Oct 2021 at 19:11, Luca Boccassi 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
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Sat, 9 Oct 2021 at 19:11, Luca Boccassi 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
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Tue, Nov 23, 2021 at 12:09 PM Lennart Poettering wrote: > > On Di, 23.11.21 11:53, Dimitri John Ledkov (dimitri.led...@canonical.com) > wrote: > > > Just an update from Ubuntu - for the upcoming release of Jammy (22.04 > > LTS targeting release in April 2022) we have started transition to > > OpenSSL 3 and currently upgrading to systemd v249. > > Did Ubuntu adopt Debian's stance of accepting OpenSSL as system > component? i.e. is OpenSSL 3 compatible with both (L)GPL 2.x code > *and* GPL3 code in Ubuntu's eyes? Or only the latter? I cannot possibly comment on or answer the above questions. You might find some related comments from Ubuntu Archive team at https://lists.ubuntu.com/archives/technical-board/2021-October/002587.html Jammy will ship OpenSSL v3. Once it migrates, I will enable Jammy CI against systemd pull requests, to ensure that the next systemd release works on Jammy. Regards, Dimitri.
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Di, 23.11.21 11:53, Dimitri John Ledkov (dimitri.led...@canonical.com) wrote: > Just an update from Ubuntu - for the upcoming release of Jammy (22.04 > LTS targeting release in April 2022) we have started transition to > OpenSSL 3 and currently upgrading to systemd v249. Did Ubuntu adopt Debian's stance of accepting OpenSSL as system component? i.e. is OpenSSL 3 compatible with both (L)GPL 2.x code *and* GPL3 code in Ubuntu's eyes? Or only the latter? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
Just an update from Ubuntu - for the upcoming release of Jammy (22.04 LTS targeting release in April 2022) we have started transition to OpenSSL 3 and currently upgrading to systemd v249. W.r.t. library choice usually GnuTLS APIs are nicer to use; however OpenSSL library tends to be the more performant one with more HW optimizations, and easier to certify. These two properties alone make me prefer OpenSSL whenever possible. Regards, Dimitri.
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Wed, 2021-09-15 at 14:29 +, Davide Cavalca 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? > > This will be an issue for CentOS Stream 8, among others. We ship a > backport of the latest systemd (and dailies from the github master) for > it as part of the CentOS Hyperscale SIG > (https://wiki.centos.org/SpecialInterestGroup/Hyperscale). C8 currently > ships OpenSSL 1.1.1k, and given that this is a package from base it's > unlikely to get bumped throughout the lifecycle of the distro. We could > theoretically build OpenSSL 3 as part of Hyperscale, but that would > require rebuilding half the distribution, which is obviously not > practical. We might be able to build and ship a coinstallable private > OpenSSL 3 build just for systemd, but I don't know how technically > feasible that'll be in practice, and it'll definitely be a pain to > maintain and likely bring along some security fun. To close the loop on this -- Michel (in CC) has built a coinstallable openssl3 package in EPEL 8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ff6e908f7e This should make it possible to continue backporting systemd on CentOS Stream 8 even after the move to openssl3. Cheers Davide
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
For some reason I sent this message to Lennart only back then, which wasn't my intention. Re-sending it to the mailing list. Am Do., 16. Sept. 2021 um 19:25 Uhr schrieb Michael Biebl : > > Hi Lennart, hi everyone! > > First, a couple of remarks regarding the Debian package: > So far, I tried to avoid enabling any OpenSSL dependent features (e.g. > repart) for the simple reason that I didn't want to pull in two SSL > stacks into systemd (we already enable GnuTLS related bits). > Consolidating around a single SSL library will definitely make this simpler. > > W.r.t. to OpenSSL 3: There is currently a package in experimental [1]. > It's possible/very likely, that its maintainer will start a transition > to OpenSSL 3 during the bookworm development cycle, which just started > now. > But there hasn't been any official announcement yet in that regard. > And given the size of the transition, I don't expect this to be > trivial [2]. I also don't expect that there will be any efforts to > make OpenSSL 1 and 3 co-installable. > This also means, that it is highly unlikely that there will be a > backport of OpenSSL for bullseye, our current stable release. > > This brings me to the next point: backports > > I typically provide backports of newer systemd versions for the > current stable release. (I did this for jessie, stretch and buster) > and I planned to do that for bullseye as well. > Mainly for two reasons: popular demand and it also proved to be useful > when filing upstream bug reports. With systemd's rather strict > requirement to only accept bug reports for the last 2 releases, it is > much easier for me to convince users to install a systemd backport > then upgrading their stable system to unstable. > > Not being able to provide this service to users for the next 2 years > is not the end of the world, but it's a bit of a nuisance. For the > second part, maybe upstream could be a bit more lenient to accept such > bug reports with older systemd versions during the transition to > OpenSSL 3? > > Last but not least: The licensing issue brought up by Luca regarding > the GPLv2 incompatibility. This is very unfortunate and I haven't > really checked if and how that affects rdeps of libsystemd0. Maybe > Luca already did that work. In this case, I'd be very interested in > his feedback here. > > Using GnuTLS would avoid all that afaics, no? > > Just curious: Can you elaborate why GnuTLS only is not an option. > > Regards, > Michael > > [1] > https://tracker.debian.org/news/1257327/accepted-openssl-300-1-source-into-experimental/ > [2] https://release.debian.org/transitions/html/auto-openssl.html > > Am Di., 14. Sept. 2021 um 13:36 Uhr schrieb Lennart Poettering > : > > > > 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
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
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. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
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. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
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 signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
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? This will be an issue for CentOS Stream 8, among others. We ship a backport of the latest systemd (and dailies from the github master) for it as part of the CentOS Hyperscale SIG (https://wiki.centos.org/SpecialInterestGroup/Hyperscale). C8 currently ships OpenSSL 1.1.1k, and given that this is a package from base it's unlikely to get bumped throughout the lifecycle of the distro. We could theoretically build OpenSSL 3 as part of Hyperscale, but that would require rebuilding half the distribution, which is obviously not practical. We might be able to build and ship a coinstallable private OpenSSL 3 build just for systemd, but I don't know how technically feasible that'll be in practice, and it'll definitely be a pain to maintain and likely bring along some security fun. The same issue applies to CentOS 7, though we've stopped building backports for that past 246 so we're not directly impacted there. Now, that good news is that this won't be an issue at all for CentOS Stream 9, as they've just rebased to 3.0.0 last week (https://gitlab.com/redhat/centos-stream/rpms/openssl). Cheers Davide
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Di, 14.09.21 10:26, Mike Gilbert (flop...@gentoo.org) wrote: > > Anyway, I'd be interested in your thoughts about this. i.e. hear > > multiple takes, opinions, from differently people and positions? > > I would definitely like to be able to depend on one crypto/TLS > implementation that would cover all features in systemd, instead of > having to depend on OpenSSL for some features, and GnuTLS for other > features. The current situation is quite messy. > > Settling on OpenSSL sounds fine to me. > > It will probably take a few months for Gentoo to get fully upgraded to > OpenSSL 3.0. Here is our tracker for that: > > https://bugs.gentoo.org/797325 > > Do you have a target date/milestone in mind for introducing this > dependency in systemd? Well, that depends on a) people actually agreeing that this is OK to do, and b) someone actually doing the work. I'd love to do it yesterday. But knowing how things work, this will be a couple of months I guess, maybe half a year. Or could even be longer. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Tue, Sep 14, 2021 at 7:36 AM 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? I would definitely like to be able to depend on one crypto/TLS implementation that would cover all features in systemd, instead of having to depend on OpenSSL for some features, and GnuTLS for other features. The current situation is quite messy. Settling on OpenSSL sounds fine to me. It will probably take a few months for Gentoo to get fully upgraded to OpenSSL 3.0. Here is our tracker for that: https://bugs.gentoo.org/797325 Do you have a target date/milestone in mind for introducing this dependency in systemd?
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On 14/09/2021 13.36, 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 am not an active developer. Nonetheless I would second this, provided the use of OpenSSL does not lead to security vulnerabilities in core non-optional system parts on systems built with the systemd project's outputs. -- Rudd-O https://rudd-o.com/ OpenPGP_signature Description: OpenPGP digital signature
[systemd-devel] [RFC] Switching to OpenSSL 3?
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
