Re: glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()

[Solar Designer <solar () openwall com>]

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.

Alexander