[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261112114033.GA167321@cventin.lip.ens-lyon.fr>
Date: Thu, 12 Nov 2026 12:40:33 +0100
From: Vincent Lefevre <vincent@...c17.net>
To: Alejandro Colomar <alx@...nel.org>
Cc: Rich Felker <dalias@...c.org>,
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 2026-11-12 11:28:20 +0100, Alejandro Colomar wrote:
> 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.
No, POSIX just says: "The algorithm is implementation-defined."
No mention of DES algorithms at all.
And note that only ENOSYS is specified as a case of failure,
which could explain why some applications do not check whether
the returned value is a null pointer (i.e. they assume that if
crypt() succeeds in usual cases, then an ENOSYS error is not
possible and crypt() never fails).
But my point was that POSIX disallows the "$" character in salt:
[...] The salt argument shall be a string of at least two bytes
in length not including the null character chosen from the set:
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9 . /
This means that when "$" is supported by some implementation,
the interpretation of the return value may be different from
what POSIX specifies.
Various people said that the choice of returning "*" in case of
failure as done by musl was a violation of POSIX. But this is
not true for 2 reasons:
* the use of the "$" character in salt by the application;
* the fact that POSIX does not give any requirement on the
hash (so the use of a hash that could be interpreted as
being invalid on the system for unsupported passwords is
a valid behavior).
--
Vincent Lefèvre <vincent@...c17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
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.
