> except a lot of programs never check for NULL. they just compare whatever crypt() gives back with the stored field, hit the NULL, and crash

> so musl (the libc under alpine) goes ok fine, crypt() just won't return NULL anymore. if it fails, it returns a single character instead.

Considering it's been accepted that crashing if malloc returns a NULL is your fault, did musl really feel the need to accommodate bad implementations like this or is this just AI speculation?

▲

red75prime an hour ago | parent | next [-]

"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]

[1] https://git.musl-libc.org/cgit/musl/commit/?id=b3c4cc121f70f...

▲

afc 25 minutes ago | parent [-]

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!"

Maybe I should update my plea to fail loudly (https://alejo.ch/3gk) to list this as an example.

	▲	01HNNWZ0MV43FF 14 minutes ago \| parent [-]
		It's always a people problem. Doing a bad patch on my side is easier than bothering anyone else to fix their code

▲

Good4boothee an hour ago | parent | prev [-]

> did musl really feel the need to accommodate bad implementations like this

I 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.

	▲	Palomides 7 minutes ago \| parent [-]
		it's not "glibc behavior", returning null on error is in the spec