Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Florian Larysch <fl@n621.de>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] package/network-manager: make cryptography library optional
Date: Fri, 30 May 2025 22:01:25 +0200	[thread overview]
Message-ID: <20250530220125.3b1c7c5f@windsurf> (raw)
In-Reply-To: <20250527152342.4288-1-fl@n621.de>

Hello Florian,

Thanks for the patch!

On Tue, 27 May 2025 17:23:38 +0200
Florian Larysch <fl@n621.de> wrote:

> The network-manager package currently pulls in either gnutls or libnss,
> neither of which are very common and it might be the only reason why
> they are present on a system.
> 
> However, most of NetworkManager works just fine without any cryptography
> support, it only seems to be used in test cases and 802.1X support code.
> 
> Make the crypto backend configurable and optional to make it possible to
> avoid this dependency while keeping the default behavior the same.
> 
> Signed-off-by: Florian Larysch <fl@n621.de>
> ---
> 
> The select vs depends on thing is a bit hacky because I've tried to set
> it up in a way that keeps the existing behavior for backwards
> compatibility. I'm not even sure if this is the best way to go about it
> or if all the options should maybe just depend on the respective
> libraries to make it less implicit.

In this kind of situation, I'm not sure keeping backward compatibility
is really a good idea. Indeed, we have two conflicting goals:

(1) Not break backward compatibility. This would encourage in
continuing to automatically select gnutls as a dependency of
network-manager, like your patch does

(2) Have minimal dependencies by default, which is one of the great
things about Buildroot: it doesn't pull in needless stuff for no
reason. This would encourage NOT automatically selecting any crypto
library by default.

And I think my preference goes to (2) in this situation.

> -ifeq ($(BR2_PACKAGE_LIBNSS),y)
> +ifeq ($(BR2_PACKAGE_NETWORK_MANAGER_CRYPTO_LIBNSS),y)
>  NETWORK_MANAGER_DEPENDENCIES += libnss
>  NETWORK_MANAGER_CONF_OPTS += -Dcrypto=nss
> -else
> +else ifeq ($(BR2_PACKAGE_NETWORK_MANAGER_CRYPTO_GNUTLS),y)
>  NETWORK_MANAGER_DEPENDENCIES += gnutls
>  NETWORK_MANAGER_CONF_OPTS += -Dcrypto=gnutls
> +else ifeq ($(BR2_PACKAGE_NETWORK_MANAGER_CRYPTO_NONE),y)
> +NETWORK_MANAGER_CONF_OPTS += -Dcrypto=null
>  endif

So the change would be just:

ifeq ($(BR2_PACKAGE_LIBNSS),y)
NETWORK_MANAGER_DEPENDENCIES += libnss
NETWORK_MANAGER_CONF_OPTS += -Dcrypto=nss
else
else ifeq ($(BR2_PACKAGE_GNUTLS),y)
NETWORK_MANAGER_DEPENDENCIES += gnutls
NETWORK_MANAGER_CONF_OPTS += -Dcrypto=gnutls
else
NETWORK_MANAGER_CONF_OPTS += -Dcrypto=null
endif

and of course drop the select in Config.in. We might discuss whether
gnutls should take priority on libnss if both are available. Maybe NM
documents that one is "better" over the other?

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2025-05-30 20:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-27 15:23 [Buildroot] [PATCH 1/1] package/network-manager: make cryptography library optional Florian Larysch
2025-05-30 20:01 ` Thomas Petazzoni via buildroot [this message]
2025-05-30 22:11   ` Florian Larysch
2025-05-31  8:56     ` Thomas Petazzoni via buildroot
2025-05-31 14:39 ` [Buildroot] [PATCH v2 0/2] package/network-manager: make crypto " Florian Larysch
2025-11-17 13:01   ` Florian Larysch
2025-05-31 14:39 ` [Buildroot] [PATCH v2 1/2] " Florian Larysch
2025-07-08  9:13   ` Marcus Hoffmann via buildroot
2026-02-03 22:01   ` Marcus Hoffmann via buildroot
2025-05-31 14:39 ` [Buildroot] [PATCH v2 2/2] package/network-manager: switch default crypto provider to gnutls Florian Larysch
2025-07-08  9:16   ` Marcus Hoffmann via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250530220125.3b1c7c5f@windsurf \
    --to=buildroot@buildroot.org \
    --cc=fl@n621.de \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox