On Wed, 2020-12-09 at 10:50 +0100, Lennart Poettering wrote: > Heya! > > Currently, some parts of the systemd tree link against OpenSSL, others > link against gnutls and libgcrypt, and even others support either, > controlled by a compile time switch. > > This is of course less than ideal, since it means we need to maintain > needlessly complex, redundant code to support this, it's not complete > (as not all combinations are supported), and footprint for general > purpose distros is effectively doubled. > > I think we should go OpenSSL all the way, and replace/drop support for > gnutls and libgcrypt, unifying on a single crypto library. This was > previously problematic since on Debian linking LGPL code against > OpenSSL was considered legally "unclean". This has recently changed > though: > > https://github.com/systemd/systemd/pull/14743#issuecomment-739001595 > > Hence, given that the legal issues around going OpenSSL exclusively > all the way are gone, I think it's time to do the full switch. Hence > I'd like to propose that we start transitioning with depending only on > OpenSSL sooner or later. This means: > > 1. Porting the currently remaining GnuTLS/gcrypt-only code over to openssl > > 2. Dropping redundant implementations for gnutls/gcrypt where we > already have openssl support > > 3. Require for new code to be openssl-only. > > Ultimately this should provide us with a smaller codebase, smaller OS > footprint and easier maintainance. > > Before we make this decision and switch over I'd like to hear opinions > on this, though. Maybe I am missing something, and there are other > reasons why people want to keep gnutls/gcrypt support around? > > Why unify on OpenSSL instead of doing it the other way and unify on > gnutls + gcrypt, btw? We don't really have any horse in that race. All > crypto libraries have well documented issues, like any code. It > appears to me though that OpenSSL has the more active and larger > community and wider industry support. It appears to me that dropping > gntuls/gcrypt frrom the basic OS package set is easier to reach then > dropping OpenSSL. In the interest of making the minimal set of OS > packages required to boot a system smaller I think OpenSSL is the > better choice. > > The fabled future OpenSSL 3 release is supposed to come with a changed > license, which will attack the Debian license incompatibility from > another angle btw. It was supposed to be released many months ago > already, afaiu, but that unfortunately never happened. So far we were > counting on this to resolve the licensing situation around crypto > libraries. Due to the Debian change I figure we can speed up things > now, though. > > Lennart Hi, I cannot think of any reason to maintain compatibility with multiple ssl libraries, nor for preferring GnuTLS/gcrypt. Choosing OpenSSL sounds just fine. With my downstream-maintainer-of-minimal-distro at $work hat on, I am super in favour for this change, and it will help us greatly. With my Debian Dev hat on, I can add that another nice thing about the recent decision by the FTP Team is that it instantly applies to all Debian releases - there is nothing to wait for, nothing to update, nothing to change. We can just start linking things, in downstreams too. And I can add a couple more references for those interested: http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html https://bugs.debian.org/972181 The only question I have is, was it checked whether the required features currently provided by GnuTLS/gcrypt are all available in OpenSSL? I know there is more or less feature parity, but devil's in the details. As far as I can see, the only pieces using GnuTLS unconditionally right now are systemd-journal-gatewayd and systemd-journal-remote. Regarding gcrypt, journald uses it for sealing and resolved for dnssec. dnssec looks like the most complex feature to port over, in terms of klocs. Everything else supports OpenSSL already. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
