[systemd-devel] RFC: Moving fully to OpenSSL (aka. stopping support for gnutls/gcrypt)?

[Arian Van Putten]

 I think it's an excellent idea.

Question:  Currently systemd-importd still has an indirect dependency on
libgcrypt through it depending on the gnupg binary for signatures.
Would it maybe be an idea to add support for other signature schemes to
importd that can be directly implemented with openssl?

A good start would be to support PKCS#7 signatures.    But we could also
opt for something more simple akin to OpenBSD signify (A simple ed25519
signature over a hash).

I personally work around this by having built https://ruuda.github.io/tako/
with a colleague which I use to download and verify nspawn container
images. But it would be cool if importd could natively support signature
checking with other backends than GnuPG.

On Wed, Dec 9, 2020 at 10:51 AM Lennart Poettering <lennart at poettering.net>
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
>
> --
> Lennart Poettering, Berlin
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 

Arian van Putten  l  Software Engineer

@arian_wire on Wire

Wire <https://wire.com/en/download/> - Secure team messaging.

 Zeta Project Germany GmbH  l  Rosenthaler Straße 40, 10178 Berlin, Germany
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>


Geschäftsführer/Managing Director: Morten J. Broegger

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20201210/d0f44ef7/attachment-0001.htm>