[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20261112162334.GN5716@brightrain.aerifal.cx>
Date: Thu, 12 Nov 2026 11:23:34 -0500
From: Rich Felker <dalias@...c.org>
To: Jeffrey Walton <noloader@...il.com>
Cc: musl@...ts.openwall.com, Lukas Tribus <lukas@...i.eu>,
Solar Designer <solar@...nwall.com>
Subject: Re: crypt: unsupported hash behavior
On Thu, Nov 12, 2026 at 11:05:58AM -0500, Jeffrey Walton wrote:
> On Thu, Nov 12, 2026 at 10:54 AM Rich Felker <dalias@...c.org> wrote:
> >
> > On Thu, Nov 12, 2026 at 10:53:13AM -0500, Rich Felker wrote:
> > > On Thu, Nov 12, 2026 at 09:53:23AM -0500, Rich Felker wrote:
> > > > On Thu, Nov 12, 2026 at 02:04:24PM +0100, Lukas Tribus wrote:
> > > > > 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.
> > > >
> > > > Yes, I've suggested we could remove the support for noncanonical DES
> > > > salts without breaking existing hashes that might exist in the wild by
> > > > doing something like, at the end of descrypt:
> > > >
> > > > if (has_bad_characters) {
> > > > if (strcmp(output,setting)) return 0;
> > > > else return output;
> > > > }
> > > >
> > > > Note that the noncanonical DES hashes are already stochastically
> > > > buggy. It's improbable but possibe for descrypt(password,"$n") to
> > > > produce a DES hash where the first few characters of the hash mimic a
> > > > valid "$n$" pattern, which when you pass the hash back to crypt, will
> > > > result in a different hash function getting used, thereby locking the
> > > > user out.
> > >
> > > Patch attached. Should we apply this now? I think it's probably a good
> > > idea. CC'ing Solar for input.
> >
> > And actually attached now.
>
> One small issue on the lowercase optimization:
>
> + return ch!='.' && ch!='/' && (ch|32)-'a'>=26U && ch-'0'>=10U;
>
> There's no guarantee ch|32 produces a lowercase character.
This is exactly testing the cases where it doesn't as one of the
conditions for rejection.
Rich
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.
