apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject More migrations from httpd to apr-util and md5 in apr
Date Wed, 23 May 2001 05:09:41 GMT
Well, now that the uri stuff is now in apr-util, the biggest one left
(IMHO) is util_date.c.  My plan is to come up with a similar series of
patches for apr_date.h.  Should a new directory be used (date)?  I also
have some additional formats that don't quite fit the HTTP RFC, but that
I saw in the creation of mod_mbox (various degrees of RFC 822
compliance) - so I might add another function (apr_parseRFCdate?) which 
attempts to parse a wider range than what the HTTP RFC specifies - this 
might be useful for some other applications, I think.

Also, the other potential candidate I identified earlier was util_md5.c.
But, it seems that util_md5.c relies on apr/passwd/apr_md5.c.  I tried to 
track down usage of apr_md5 within apr itself, and the only usage I could 
find was in apr/misc/unix/getuuid.c which will only uses apr_md5 when 
APR_HAS_RANDOM is not defined (typically /dev/random doesn't exist - i.e.
Solaris doesn't have it, or truerand isn't available).  This seems odd.  
It just md5s the current date/hostname/pid to produce a "random" string 
of the requested length.  I *guess* it's random enough.

Now, I'm not sure what the dividing line is between apr and apr-util, 
but my gut tells me that md5 hashing doesn't belong in apr itself.  I 
think a better (IMHO) solution (if I interpret the use of md5 in getuuid.c 
correctly) is to introduce some PRNG into apr and move md5 into apr-util.  
This also has the side effect of guaranteeing that there is always some 
PRNG available.  As I see it, this PRNG would be used as a fallback 
when /dev/random and friends aren't available.

I bet there are some free PRNGs (BSD-license of course) flying around 
that could be used, or we could try to come up with one of our own.  I'd 
rather not reinvent the wheel (PRNGs aren't trivial), but hey, I'm game.  
Maybe a better solution to the PRNG is try to leverage rand() somehow,
and coersce it to fit the apr_generate_random_bytes prototype.  Make the
rand() % CHAR_MAX for each byte.  That is simplisitic and wouldn't be
that efficient.  We'd also have to determine whether any PRNG is good
enough for inclusion with APR for when it is used as a fallback.  I
don't think including a sub-par PRNG is a good idea (any idea what the
definition for a sub-par PRNG is?  <G>).  You'd also have to deal with 
seeding the rand() function (in apr_initialize?).

Thoughts?  -- justin

View raw message