<div dir="ltr"><div> I think it's an excellent idea. </div><div>Question: Currently systemd-importd still has an indirect dependency on libgcrypt through it depending on the gnupg binary for signatures. </div><div>Would it maybe be an idea to add support for other signature schemes to importd that can be directly implemented with openssl? </div><div>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). </div><div>I personally work around this by having built <a href="https://ruuda.github.io/tako/">https://ruuda.github.io/tako/</a> 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.</div></div> <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: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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: <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> 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 <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div> -- <div dir="ltr" class="gmail_signature"><div dir="ltr">Arian van Putten l Software Engineer@arian_wire on Wire<a href="https://wire.com/en/download/" target="_blank">Wire</a> - Secure team messaging. Zeta Project Germany GmbH l <a href="https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g" target="_blank">Rosenthaler Straße 40, 10178 Berlin, Germany</a> Geschäftsführer/Managing Director: Morten J. BroeggerHRB 149847 beim Handelsregister Charlottenburg, BerlinVAT-ID DE288748675</div></div>