[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACC_My8D-PR_qeQaZfMdi-6cFGm1RqkrYBEWpUXChb2MoN+S1w@mail.gmail.com>
Date: Thu, 12 Nov 2026 14:04:24 +0100
From: Lukas Tribus <lukas@...i.eu>
To: musl@...ts.openwall.com
Subject: crypt: unsupported hash behavior
Hello,
I'm aware of the short term intention to modify the crypt() error
token from * to *0 mimicking libxcrypt and the long term intention of
returning NULL (which is what RHEL9/10 already does because libxcrypt
is build with --disable-failure-tokens), both changes I think are
great.
In haproxy, we use crypt/crypt_r for authentication purposes and at
startup we check whether the hashes are supported by passing an empty
password with the salt to crypt() to determine whether the hash type
is supported:
hash = crypt("", args[cur_arg + 1]);
if (!hash || hash[0] == '*') {
ha_alert("parsing [%s:%d]: the encrypted password used for user '%s'
is not supported by crypt(3).\n",
file, linenum, newuser->user);
}
We used to just check for NULL which worked fine in RHEL9/10 due to
libxcrypt--disable-failure-tokens; we added a check for * the other
day, which makes this work in non-RHEL glibc/libxcrypt distribution
like Debian.
AFAIK returning an error when a unknown hash type is a implementation
detail of glibc crypt/libxcrypt.
It does not happen in musl's crypt.
My question is whether it would be possible to implement the stricter
libxcrypt behavior even though there is no "contract" (POSIX or
otherwise) requiring it. As this is already the case in libxcrypt and
likely in the previous glibc implementation, I don't think we would be
upsetting applications.
Thanks,
Lukas
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
