Re: [systemd-devel] [PATCH] man: add instruction on clearing file descriptors

[Lennart Poettering]

On Mo, 07.12.20 19:42, Mantas Mikulėnas (graw...@gmail.com) wrote:

> I'm not sure if it's more portable. I recall FreeBSD only exposing 0–2 in
> its /dev/fd by default unless you mounted a separate virtual filesystem
> there. NetBSD seems to always have 64 devnodes no matter how many fds.
>
> I don't think there's a *good* portable method (which is why closerange()
> is being added) and besides that I'm not sure if that is even in scope for
> this systemd-centric manpage...the whole idea is that under systemd, a
> daemon shouldn't need that.

Yes, I fully agree. This is messy and generally not portable. If you
care about portability maybe go the RLIMIT_NOFILE way, which is of
course terrible inefficient, but that's the price you have to pay for
portability I guess.

Anyway, I don't think mentioning /dev/fd/ is generally helpful, it's
misleading at best I think.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH RFC 1/1] module: delay kobject uevent until after module init call

[Jessica Yu]

+++ Jessica Yu [03/12/20 14:51 +0100]:

Apparently there has been a longstanding race between udev/systemd and
the module loader. Currently, the module loader sends a uevent right
after sysfs initialization, but before the module calls its init
function. However, some udev rules expect that the module has
initialized already upon receiving the uevent.

This race has been triggered recently (see link in references) in some
systemd mount unit files. For instance, the configfs module creates the
/sys/kernel/config mount point in its init function, however the module
loader issues the uevent before this happens. sys-kernel-config.mount
expects to be able to mount /sys/kernel/config upon receipt of the
module loading uevent, but if the configfs module has not called its
init function yet, then this directory will not exist and the mount unit
fails. A similar situation exists for sys-fs-fuse-connections.mount, as
the fuse sysfs mount point is created during the fuse module's init
function. If udev is faster than module initialization then the mount
unit would fail in a similar fashion.

To fix this race, delay the module KOBJ_ADD uevent until after the
module has finished calling its init routine.

References: https://github.com/systemd/systemd/issues/17586
Signed-off-by: Jessica Yu 


Thanks all, this has been applied to modules-next to try to get as
much -next time as possible before the upcoming merge window.

Jessica

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Do, 10.12.20 10:58, Arian Van Putten (ar...@wire.com) wrote:

>  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?

Yes, ed25519 sounds like an excellent choice.

systemd-homed exclusively signs its user records with ed25519 btw.

> 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).

The kernel supports validating dm-verity images with PKCS#7 hashes,
which we support in RootHashSignature= in unit files. (These are
signatures of the root hash of the dm-verity Merkle tree, not
signatures of the image as a whole, though).

> 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.

I am totally on board with this. Both ed25519 and PKCS#7 appear a
million times better than gpg for things like this. We have code for
both already in place in one form or another.

I'd be fine supporting both for importd. I am not a fan of gpg, and
would much rather have everyone use either ed25519 or PKCS#7 for this.

Looking forward to your patches ;-)

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [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 
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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 

Arian van Putten  l  Software Engineer

@arian_wire on Wire

Wire  - Secure team messaging.

 Zeta Project Germany GmbH  l  Rosenthaler Straße 40, 10178 Berlin, Germany



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

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] (no subject)

[Noe Rentería]

Ok
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Umut Tezduyar Lindskog]

Hi. Really good initiative!

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.

Umut

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