Russ Allbery <rra <at> debian.org> writes: > (consider resource exhaustion errors in the crypt implementation, for
No, the standard said it would either always fail or never, but independent on the input data. > Your proposed solution on libc-alpha was ingenious, but I think it breaks > the crypt contract in even more serious ways, since it means that crypt > could now return a string matching the disabled password field in No, it cannot, because you pass the “password field” as seed, hence the comparison: if the password field is disabled by ‘*’ you get ‘x’, if it’s disabled by ‘x’ got get ‘*’. It always returns something not matching. And prevents serious security issues in legacy code (which, by the way, often predates the standard and thus is allowed to not follow it). bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130925t134128-...@post.gmane.org
