"unfortunately, a large portion of programs which call crypt are not
prepared for its failure and do not check that the return value is
non-null before using it. thus, always "succeeding" but giving an
unmatchable hash is reportedly a better behavior than failing on
error." [1]
reply[1] https://git.musl-libc.org/cgit/musl/commit/?id=b3c4cc121f70f...
Such a questionable decision! "Rather than let a bug in a caller (not handling the valid null output and thus crashing) surface, let's just silence it and pretend that the caller is correct! A potential clash in some situations (resulting in this vulnerability) is better than a crash!"
replyMaybe I should update my plea to fail loudly (https://alejo.ch/3gk) to list this as an example.
It's always a people problem. Doing a bad patch on my side is easier than bothering anyone else to fix their code
reply> did musl really feel the need to accommodate bad implementations like this
replyI don't know about this specific case but in general? Yes, totally. No one is going to fix all existing software that depends on libs behaving exactly as glibc, you have to accept some trade-offs. Either your new implementation stops being perfectly simple and clean, or no one uses it.
it's not "glibc behavior", returning null on error is in the spec
replySee also: Hyrum's Law
reply