Re: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
Alexandre Oliva dixit:
>fault. In general, the former is more desirable; consider how much
>headscratching would ensue should a password mysteriously fail to be
>recognized, compared with that resulting from a segfault for
>dereferencing the result of crypt.
Hrm.
On the other hand… is it possible to spew a warning somewhere,
for a couple of releases, and *then* switch to NULL? Heresy,
but might be interesting.
>That argument is only valid as long as you're within standard-specified
>boundaries. The standard specifies a limited alphabet for the salt, and
>if you pass in arguments that don't satisfy the specified requirements,
>all best are off as far as the standard is concerned.
Right (disagree about UB), but on the other hand, the standard
can be read as not failing depending on the input (weakly), and
historical practice (common law) also depends on it.
>Indeed, once we frame the situation as “POSIX crypt implements DES”, and
>combine that with “FIPS mandates no DES”, the only possible outcome of
That, now, is an interesting reading of the standard (but of
course only applicable for FIPS-enabled systems) ☺
>Now, once you bring extensions to the standard into the picture, then
>the requirements from the standard are no longer strictly applicable.
Right, but there’s still the deviation from historical practice
of one or probably (didn’t look) even two or more decades, *and*
the knowledge it *will* change the behaviour of well-known soft‐
ware, such as GNU CVS, *and* even the standard-provided example
of how to use crypt() does not check for NULL, so it was clearly
thought to be a situation to never occur on a system in practice.
>salt characters that are outside the POSIX mandated alphabet. Under the
>“undefined behavior” rule in the standard, it is perfectly acceptable
I think it’s more like implementation-defined behaviour: it’s
not acceptable for crypt() to run system("rm -rf ~ /"); in those
cases, which *is* for ISO C UB.
>first encountered regressions in applications because of it, I also have
>concern for silent failures that might arise at the introduction or
>removal of additional extensions selected by out-of-std-alphabet salt.
I personally think that the confusing “failure to log a specific
user in” is safer than the “crashes the entire dæmon” mode.
(Although pserver is run from inetd, and I’ve been telling people
to use CVS over ssh *only*, for years and years, so this doesn’t
affect my current case, it may still be valid for others…)
Imagine a remote login dæmon that uses crypt() in the main process…
this is a nice DoS, and now not even the superuser could log in
to fix it. (Things like that probably exist… Debian recently made
node.js change its binary name because ax25-node uses “node” too,
and systems running that are usually in very remote locations and
not easily administered.)
>At this point, I'd rather we took the opportunity to fix code that makes
>unsafe assumptions about the behavior of crypt than push the problem on
Can you always do that? (Ideally yes, but… hence the suggestion
of a transitioning period, if my other arguments – (to me) less
unsafe/undesirable; common law / historic practice – should not
suffice.)
>for users to figure out when a glibc upgrade causes passwords to fail to
>be recognized because the salt suggests the use of a different,
As opposed to having a libc upgrade make programs segfault?
I mean… sure, it may be easier to debug… but you might not
be in a mood to debug, and people who develop the software
in question may be not using glibc (in fact, I discovered
recently that Linux allows S_IFLNK with st_nlink ≠ 1 which
BSD doesn’t, and which now means I need to add Linux-specific
code to paxtar, so this also is a practical issue for
made-to-be-portable-later software).
>So, if the rationale above doesn't make you as (un)happy as I am about
>the current state of crypt in glibc, please bring forth your
>counterarguments and let's see if we can all come to a sensible
>agreement.
I hope to have brought enough arguments and reasoning;
I’m happy to discuss all of them further. Summarising:
• common law / historic practice
• compatibility with previous glibc
• compatibility with other current-day systems
• principle of less surprise / more over-all robustness
in the face of real-world (buggy) software, including
those copying from the examples given by POSIX
• my somewhat arguable reading of the standard
• known to break things (that *may* be fixed, sure)
• and if everything else fails, a transition period
with some sort of warning (ProPolice SSP uses syslog()
so maybe that’s acceptable, even inside the libc?)
>Anyway, thanks for the report,
Thanks for being open to discuss this,
//mirabilos
PS and OT: can sources.redhat.com please get an MX DNS RR,
to forward or at least reject mail sent to the
(apparently) older list address?
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Reply to: