Aurelien Jarno dixit:
>As the function is POSIX compliant, it looks like to me a documentation
>issue. Should this bug be reassigned to manpages-dev to mention the fact
>that the function might return NULL in case of error?
The NULL-in-case-of-error mentioned by POSIX is when the
function is not implemented *at all*, i.e. all calls to
it would fail independent of the input (and then, you’d
have bigger problems).
Even the example code given in POSIX uses crypt() without
checking for NULL explicitly, assuming it’ll always get a
string out that just won’t compare equally if it’s not a
valid password.
There’s bound to be lots of software that uses crypt() like
this, especially as this behaviour has been in existence for
*decades* literally, and will continue to be on other OSes.
This probably *will* introduce security holes, especially
when the password hash is user-controlled; libc should behave
sanely here and just fall back to “DES”. Or just return "*"
unless the argument is "*" in which case it can return "x".
I find it especially poor form of GNU when the GNU libc
breaks other GNU software…
bye,
//mirabilos
--
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
