You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Stas Bekman <st...@stason.org> on 2003/03/21 02:34:57 UTC
the issue with apr_generate_random_bytes
Hmm, now I see why apr_generate_random_bytes is not exported on AIX. For some
reason I was checking apr.exp on linux and thought it was just a bug in older
apr versions that apr_generate_random_bytes wasn't exported. my bad. So we have:
#if APR_HAS_RANDOM
...
APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
apr_size_t length);
...
I thought that apr_ namespace includes only functions available on all
supported platforms. Is that a wrong assumption?
it looks that one of the linking problems that I had with libapr was due to
this issue. one of the mod_perl libs provided a perl glue for this function,
but the function wasn't available on AIX.
How this situation should be handled? Should we drop the provision of the perl
glue for this function, as it might be unavailable?
Are there other apr_ functions that are subject to availability?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the issue with apr_generate_random_bytes
Posted by Branko Čibej <br...@xbc.nu>.
Stas Bekman wrote:
> Branko Čibej wrote:
>
>> Yup. There's no apr_fork on Windows, for instance.
>
>
> mod_perl's APR Perl API doesn't provides a glue for this one, because
> perl already provides fork() which works on all platforms, including
> win32.
Uh huh. Yes, perl's fork() "works" on Win32, if "work" is defined as
"not freak out". But it doesn't fork the process, as I was "happy" to
find out. At least, it doesn't in ActivePerl's Perl 5.8 port.
[snip]
> However in the case of APR_HAS_RANDOM we will simply drop
> apr_generate_random_bytes from the APR:: Perl API, because mod_perl
> code should work everywhere unconditionally, just like Perl does. A
> true write once run anywhere ;)
Yes, and not just write-once, it's also write-only -- 90% of the time
nobody can read what someone else has written in Perl. :-)
> Thank you Branko!
No trouble.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: non-availability of APR_HAS_RANDOM implications on security
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 21, 2003 1:52 PM +1100 Stas Bekman <st...@stason.org> wrote:
> However apr-util/crypto/getuuid.c provides a *sort of* random implementation
> where APR_HAS_RANDOM is not available in two functions. in the true_random()
> we have this nice note:
>
> /* crap. this isn't crypto quality, but it will be Good Enough */
IMHO, UUID's don't need crypto-quality random numbers - therefore, the
pid/time hacks are good enough just for UUID's but not in the general case.
I'm sure someone will disagree with me though. -- justin
non-availability of APR_HAS_RANDOM implications on security
Posted by Stas Bekman <st...@stason.org>.
I was looking at the actual usage of apr_generate_random_bytes in httpd/apr
projects.
mod_auth_digest.c will refuse to build if APR_HAS_RANDOM is not available.
Which is a clean solution.
However apr-util/crypto/getuuid.c provides a *sort of* random implementation
where APR_HAS_RANDOM is not available in two functions. in the true_random()
we have this nice note:
/* crap. this isn't crypto quality, but it will be Good Enough */
This seems fishy, user that doesn't have the random library installed may
falsely think that his apps are safe, since apr-util does absolutely nothing
in order to warn the user of a potential problem. Unless I'm missing it.
I'd suggest to refuse to compile, till a user explicitly provides a flag
saying: --I_do_not_care_about_security, which may trigger some action on their
behalf if they are going to use this function. May be we shouldn't make it too
hard on the users who don't use these functions, so instead we could have a
run-time assertion, which will be disabled if re-compiled with
--I_do_not_care_about_security.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the issue with apr_generate_random_bytes
Posted by Stas Bekman <st...@stason.org>.
Branko Čibej wrote:
> Stas Bekman wrote:
>
>
>>Hmm, now I see why apr_generate_random_bytes is not exported on AIX.
>>For some reason I was checking apr.exp on linux and thought it was
>>just a bug in older apr versions that apr_generate_random_bytes wasn't
>>exported. my bad. So we have:
>>
>>#if APR_HAS_RANDOM
>>...
>>APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
>> apr_size_t length);
>>...
>>
>>I thought that apr_ namespace includes only functions available on all
>>supported platforms. Is that a wrong assumption?
>
>
> Yup. There's no apr_fork on Windows, for instance.
mod_perl's APR Perl API doesn't provides a glue for this one, because perl
already provides fork() which works on all platforms, including win32.
>>it looks that one of the linking problems that I had with libapr was
>>due to this issue. one of the mod_perl libs provided a perl glue for
>>this function, but the function wasn't available on AIX.
>>
>>How this situation should be handled? Should we drop the provision of
>>the perl glue for this function, as it might be unavailable?
>
>
> I'd say that's mod_perl's problem. It should check APR_HAS_RANDOM.
It is, I just wasn't aware of it till I started to port mod_perl build on AIX.
That's what happening when you develop and test things on a platform which
happens to support everything (linux) ;)
>>Are there other apr_ functions that are subject to availability?
>
>
> Off the top ot my head: APR_HAS_FORK, APR_HAS_THREADS. Possibly others.
APR_HAS_THREADS is a bit different, since it's needed to support the threaded
mpms. So we do check for it.
However in the case of APR_HAS_RANDOM we will simply drop
apr_generate_random_bytes from the APR:: Perl API, because mod_perl code
should work everywhere unconditionally, just like Perl does. A true write once
run anywhere ;)
Thank you Branko!
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the issue with apr_generate_random_bytes
Posted by Branko Čibej <br...@xbc.nu>.
Stas Bekman wrote:
> Hmm, now I see why apr_generate_random_bytes is not exported on AIX.
> For some reason I was checking apr.exp on linux and thought it was
> just a bug in older apr versions that apr_generate_random_bytes wasn't
> exported. my bad. So we have:
>
> #if APR_HAS_RANDOM
> ...
> APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
> apr_size_t length);
> ...
>
> I thought that apr_ namespace includes only functions available on all
> supported platforms. Is that a wrong assumption?
Yup. There's no apr_fork on Windows, for instance.
> it looks that one of the linking problems that I had with libapr was
> due to this issue. one of the mod_perl libs provided a perl glue for
> this function, but the function wasn't available on AIX.
>
> How this situation should be handled? Should we drop the provision of
> the perl glue for this function, as it might be unavailable?
I'd say that's mod_perl's problem. It should check APR_HAS_RANDOM.
> Are there other apr_ functions that are subject to availability?
Off the top ot my head: APR_HAS_FORK, APR_HAS_THREADS. Possibly others.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/