mailing list archives
Re: glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()
From: Solar Designer <solar () openwall com>
Date: Fri, 30 Mar 2012 23:05:32 +0400
On Fri, Mar 30, 2012 at 12:47:54PM -0600, Jeff Law wrote:
On 03/30/2012 12:43 PM, Solar Designer wrote:
On Fri, Mar 30, 2012 at 12:27:31PM -0600, Jeff Law wrote:
I think the right way to handle the return value is to return NULL for
these cases. It's posix complaint and the glibc crypt routines already
return NULL for exceptional conditions.
Do you realize that plenty of services that use crypt() - likely the
majority of them, even - don't handle NULL returns, so they will
segfault when these conditions are triggered?
Then, IMHO, the app is clearly broken. Crypt has been defined as
potentially returning NULL and at least for glibc has done so since the
introduction of sha256/sha512, if the app fails to check for that, then
the app needs to be fixed.
Sure. I am not arguing against fixing the apps (in fact, I am planning
to fix one of mine - code originally written in 1998 or so - regardless
of what glibc does on this), but I am arguing for not having glibc
expose the problem.
Considering the age of Unix, SUSv2 and POSIX.1-2001 are fairly recent
(I think this may be when the NULL returns were first standardized), and
glibc's SHA-crypt is very young. It still makes sense to support apps
older than that, including without changes.
I don't speak for glibc on this issue, so if you want to raise it on
libc-alpha, go for it.
I was hoping that you would take care of that. ;-)
Anyway, given DragonFly's decision, various other systems returning NULL
on various occasions (inconsistently), and your comment about glibc
doing that for a while, I no longer have a strong opinion on the matter.
We will likely continue to do the "*0" / "*1" thing in Owl (our distro
that uses glibc with patches), though.