<div dir="ltr">Hi. Really good initiative!<div><br></div><div>Also wanted to inform about connectedhomeip project which has an abstraction layer for OpenSSL and Mbed TLS. Probably the layer is far from being ready for systemd to use though.</div><div><br></div><div>Umut</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 10:51 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Heya!<br>
<br>
Currently, some parts of the systemd tree link against OpenSSL, others<br>
link against gnutls and libgcrypt, and even others support either,<br>
controlled by a compile time switch.<br>
<br>
This is of course less than ideal, since it means we need to maintain<br>
needlessly complex, redundant code to support this, it's not complete<br>
(as not all combinations are supported), and footprint for general<br>
purpose distros is effectively doubled.<br>
<br>
I think we should go OpenSSL all the way, and replace/drop support for<br>
gnutls and libgcrypt, unifying on a single crypto library. This was<br>
previously problematic since on Debian linking LGPL code against<br>
OpenSSL was considered legally "unclean". This has recently changed<br>
though:<br>
<br>
<a href="https://github.com/systemd/systemd/pull/14743#issuecomment-739001595" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/pull/14743#issuecomment-739001595</a><br>
<br>
Hence, given that the legal issues around going OpenSSL exclusively<br>
all the way are gone, I think it's time to do the full switch. Hence<br>
I'd like to propose that we start transitioning with depending only on<br>
OpenSSL sooner or later. This means:<br>
<br>
1. Porting the currently remaining GnuTLS/gcrypt-only code over to openssl<br>
<br>
2. Dropping redundant implementations for gnutls/gcrypt where we<br>
already have openssl support<br>
<br>
3. Require for new code to be openssl-only.<br>
<br>
Ultimately this should provide us with a smaller codebase, smaller OS<br>
footprint and easier maintainance.<br>
<br>
Before we make this decision and switch over I'd like to hear opinions<br>
on this, though. Maybe I am missing something, and there are other<br>
reasons why people want to keep gnutls/gcrypt support around?<br>
<br>
Why unify on OpenSSL instead of doing it the other way and unify on<br>
gnutls + gcrypt, btw? We don't really have any horse in that race. All<br>
crypto libraries have well documented issues, like any code. It<br>
appears to me though that OpenSSL has the more active and larger<br>
community and wider industry support. It appears to me that dropping<br>
gntuls/gcrypt frrom the basic OS package set is easier to reach then<br>
dropping OpenSSL. In the interest of making the minimal set of OS<br>
packages required to boot a system smaller I think OpenSSL is the<br>
better choice.<br>
<br>
The fabled future OpenSSL 3 release is supposed to come with a changed<br>
license, which will attack the Debian license incompatibility from<br>
another angle btw. It was supposed to be released many months ago<br>
already, afaiu, but that unfortunately never happened. So far we were<br>
counting on this to resolve the licensing situation around crypto<br>
libraries. Due to the Debian change I figure we can speed up things<br>
now, though.<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</blockquote></div>