Re: [Buildroot] [PATCH] package/openssh: enable DES when using libopenssl

Thomas Petazzoni via buildroot <[email protected]>
Newsgroups net.busybox.buildroot
Message-ID <aohFF1WM2HaL7WU9@windsurf>
Hello Jimmy, Hello Peter,

On Tue, Jul 28, 2026 at 10:42:20PM +0200, Peter Korsgaard wrote:

>  > Signed-off-by: Jimmy Durand Wesolowski <[email protected]>
> 
> Hmm, with what configuration is this? Presumably not one where
> BR2_PACKAGE_OPENSSH_SERVER is enabled, as that pulls in libxcrypt on
> glibc?

Issue can be reproduced with:

  BR2_aarch64=y
  BR2_TOOLCHAIN_EXTERNAL=y
  BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
  BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
  BR2_INIT_NONE=y
  BR2_SYSTEM_BIN_SH_NONE=y
  # BR2_PACKAGE_BUSYBOX is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_CHACHA is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_RC2 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_RC4 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_MD2 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_MD4 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_MDC2 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_BLAKE2 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_IDEA is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_SEED is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_DES is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_RMD160 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_WHIRLPOOL is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_BLOWFISH is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_SSL is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_SSL3 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_WEAK_SSL is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_PSK is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_CAST is not set
  # BR2_PACKAGE_LIBOPENSSL_UNSECURE is not set
  # BR2_PACKAGE_LIBOPENSSL_DYNAMIC_ENGINE is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_COMP is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_ARGON2 is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_CACHED_FETCH is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_CMP is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_THREAD_POOL is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_ECX is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_PADLOCK_ENGINE is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_MODULE is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_QUIC is not set
  # BR2_PACKAGE_LIBOPENSSL_SECURE_MEMORY is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_SIV is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_SM2_PRECOMP_TABLE is not set
  # BR2_PACKAGE_LIBOPENSSL_ENABLE_SSL_TRACE is not set
  BR2_PACKAGE_OPENSSH=y
  # BR2_PACKAGE_OPENSSH_SERVER is not set
  # BR2_PACKAGE_OPENSSH_KEY_UTILS is not set
  # BR2_PACKAGE_OPENSSH_SANDBOX is not set
  # BR2_TARGET_ROOTFS_TAR is not set

So basically, OpenSSH enabled, client only (since enabling the server
would pull in libxcrypt) and disabling all OpenSSL sub-options.

The code in OpenSSH goes like this:

# if defined(WITH_OPENSSL) && !defined(HAVE_CRYPT) && defined(HAVE_DES_CRYPT)
#  include <openssl/des.h>
#  define crypt DES_crypt
# endif

So basically, the idea is that if we have OpenSSL, we don't have
crypt(), but we have DES_crypt, then we use DES_crypt() as
crypt(). Otherwise, the crypt() call in the OpenSSH xcrypt() function
remains crypt(), and things blow up when you're building with glibc
and you don't have libxcrypt around to provide crypt().

So indeed, we have two options here:

- Always provide a crypt() implementation by making libxcrypt
  mandatory for OpenSSH as a whole, not just for the server-side

- Require OpenSSH to provide DES support, which is what Jimmy was
  proposing.

I honestly don't have a strong argument. My vague feeling is that DES
being obsolete, it feels odd to be forced to enable it. Though perhaps
libxcrypt would in fact provide exactly the same obsolete crypto
algorithm?

Peter: thoughts?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.