On Jul 1, 2013, Thorsten Glaser <t...@mirbsd.de> wrote: > This would always avoid returning a NULL value, thus unbreaking > all applications that use that assumption.
It seems to me that this would turn a very visible fault into a silent 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. > the argument that crypt() must either always return NULL or never, 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. It's undefined behavior, that could take such forms as returning NULL or any random pointer to garbage, crashing, running DES or any other algorithm on the inputs disregarding or not the salt, stealing your life partner or destroying the universe ;-) Indeed, once we frame the situation as “POSIX crypt implements DES”, and combine that with “FIPS mandates no DES”, the only possible outcome of combining both requirements is to conclude that POSIX crypt must be disabled altogether, which is perfectly compatible with returning NULL and setting errno when crypt is called in a standard-compliant way: that functionality is not available. Now, once you bring extensions to the standard into the picture, then the requirements from the standard are no longer strictly applicable. That's why the choice of alternate encryption algorithms is done using salt characters that are outside the POSIX mandated alphabet. Under the “undefined behavior” rule in the standard, it is perfectly acceptable for the implementation to behave however it likes; under the rules of each individual extension, it is perfectly ok for the implementation to recognize the requests for the extension to be used and proceed to encrypt accordingly. Which leaves us with the cases of an extension that is disabled, not implemented, or not even known of. I see no reason to treat them differently it from the case in which DES crypt is requested but it's not available (disabled or not implemented): return NULL, setting errno accordingly. > • returning NULL if it’s not valid DES (or an otherwise unrecognised > algorithm, e.g. #if !__OPTION_EGLIBC_CRYPT_UFC, probably too) is > just the wrong thing to do, and it does break GNU CVS, among others. While I had a great concern with this sort of breakage, to the point of having voiced concerns when I first proposed the patch, and when we 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. If, when we fail to recognize an extension, we fallback to DES crypt, we generate encrypted passwords that will fail to verify by implementations that recognize the extension, and vice-versa. This is a far more confusing failure mode, which makes it far less desirable to me. 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 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, newly-recognized encryption algorithm. This is my current rationale for the current implementation, after two rounds of discussion on its merits. I must admit I'm not comfortable with the change that was made to out-of-alphabet DES salt, but ATM I'm even less comfortable with the alternatives. I didn't always favor the current situation, and that might change again depending on arguments I get. But then, I don't have the final word on any of this ;-) 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. Anyway, thanks for the report, -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
