[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261109183952.GN23438@brightrain.aerifal.cx>
Date: Mon, 9 Nov 2026 13:39:52 -0500
From: Rich Felker <dalias@...c.org>
To: Seo Suchan <tjtncks@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Re: RFC: how to document musl-crypt failure ?
On Tue, Nov 10, 2026 at 03:31:08AM +0900, Seo Suchan wrote:
> About musl, as it doesn't error at invalid hash but fall back to
> des. so client using it should check returned hash is expected
> length of that algorithm when you make new password: it may just
> silently interpret it as des hash request because it didn't
> understand hash algorithm. (Ex: busybox passwd with yestcrypt option
> that musl doesn't support
Thanks for bringing this up. I've had some discussions off-list about
this, looking for viable ways to make it so settings strings with
bytes outside the DES base64 character set can't be used for hashing
new passwords, while not locking out anyone who might have such a
password. The logic is probably something like (pseudocode):
if (relaxed_descrypt(pass,hash)==hash) return hash;
else return NULL; // or failure token if still in use
If we do something like this it will be at least in the next release
cycle (not current bugfix one). But it depends on assessment of
whether this is safe and nonbreaking.
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.
