You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joe Orton <jo...@manyfish.co.uk> on 2003/05/28 21:57:27 UTC

Re: cvs commit: apr-util/test testpass.c .cvsignore Makefile.in

On Wed, May 28, 2003 at 04:45:46AM -0000, Justin Erenkrantz wrote:
> jerenkrantz    2003/05/27 21:45:46
> 
>   Modified:    .        CHANGES configure.in
>                build    apu-hints.m4
>                crypto   apr_md5.c
>                test     .cvsignore Makefile.in
>   Added:       test     testpass.c
>   Log:
>   SECURITY [httpd incident CAN-2003-0189] Address a thread safety issue with
>   apr_password_validate() on AIX, Linux, Mac OS X, and possibly other platforms.
>   
>   We didn't move the crypt_r checks from apr to apr-util when we moved
>   apr_password_validate.  Add testpass.c to ensure we don't regress.

I looked into moving the macro but there was a nasty gotcha, maybe this
is what you found too: the glibc-style crypt_r implementation relies on
-D_GNU_SOURCE being in CPPFLAGS, but any additions to CPPFLAGS made by
the apr-util configure script are dropped on the floor. (since
apr-util/crypto/Makefile just includes apr_rules.mk from APR)

joe

Re: cvs commit: apr-util/test testpass.c .cvsignore Makefile.in

Posted by Jeff Trawick <tr...@attglobal.net>.
Joe Orton wrote:
> On Wed, May 28, 2003 at 04:45:46AM -0000, Justin Erenkrantz wrote:
> 
>>jerenkrantz    2003/05/27 21:45:46
>>
>>  Modified:    .        CHANGES configure.in
>>               build    apu-hints.m4
>>               crypto   apr_md5.c
>>               test     .cvsignore Makefile.in
> I looked into moving the macro but there was a nasty gotcha, maybe this
> is what you found too: the glibc-style crypt_r implementation relies on
> -D_GNU_SOURCE being in CPPFLAGS, but any additions to CPPFLAGS made by
> the apr-util configure script are dropped on the floor. (since
> apr-util/crypto/Makefile just includes apr_rules.mk from APR)

I don't recall anybody encountering this, but its a great heads up.

Certainly it is appropriate for aprutil configure to be able to add 
stuff to CFLAGS/CPPFLAGS, and that should be fixed, but my own feeling 
about feature set selection symbols like _GNU_SOURCE is that they should 
be defined in apr_hints.m4.  In general, changing at mid-stream which 
flavor of system interfaces we want or which set of system interfaces we 
want can lead to inconsistencies w.r.t. any config tests done prior to 
the point that we start defining the symbol.