[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261112120831.GH5716@brightrain.aerifal.cx>
Date: Thu, 12 Nov 2026 07:08:32 -0500
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: Vincent Lefevre <vincent@...c17.net>,
Alejandro Colomar <alx+linux-man@...nel.org>,
linux-man@...r.kernel.org, libc-alpha@...rceware.org,
Walter Harms <wharms@....de>, ~hallyn/shadow@...ts.sr.ht,
musl@...ts.openwall.com
Subject: Re: Re: [PATCH v1] man/man3/crypt.3: These functions accept
many algorithms, not only DES
On Thu, Nov 12, 2026 at 11:28:20AM +0100, Alejandro Colomar wrote:
> Hi Rich, Vincent,
>
> > Date: 2026-11-11 22:37:42-0500
> > From: Rich Felker <dalias@...c.org>
> >
> > On Thu, Nov 12, 2026 at 04:29:29AM +0100, Vincent Lefevre wrote:
> > > On 2026-11-11 21:53:39 -0500, Rich Felker wrote:
> > > > That's the whole reason '$' was chosen: POSIX doesn't define the
> > > > behavior (since a "shall" is violated) so the implementation is free
> > > > to define a behavior here. The behaviors for the portable base64
> > > > character set documented in POSIX uses only 2 characters as salt
> > > > (insufficient) and the common agreed-upon definition for how they are
> > > > used is as salt for the classic DES-based password hash.
> > >
> > > But the behavior is completely out of scope of POSIX.
> >
> > Yes. And that's allowed because POSIX does not define the behavior but
> > leaves it undefined. I'm not sure if you're objecting to something
> > here or questioning how it should be documented or something else..?
>
> Yeah, I think it'd be okay to document that this is an extension to
> POSIX. Perhaps, we could add this:
>
> @@ -111,6 +111,9 @@ .SH ATTRIBUTES
> .BR crypt_r ()
> T} Thread safety MT-Safe
> .TE
> +.SH VERSIONS
> +While POSIX only specifies the DES algorithms for these functions,
> +all systems implement several other algorithms.
POSIX doesn't specify any algorithm. It specifies the input format for
salt in a way that's aligned with the traditional DES password hashing
algorithm but it doesn't assign any actual definition for the
algorithm.
DES hash provides the implementation-defined algorithm POSIX mandates
exists but doesn't specify. The other hashes fill in the gaps where
the specification leaves things undefined.
For practical purposes POSIX is irrelevant to the way you choose salt
strings for producing new password hashes; it only specifies how to
call the function and validate a password against a hash.
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.
