apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: More migrations from httpd to apr-util and md5 in apr
Date Wed, 23 May 2001 23:18:17 GMT
On Tue, May 22, 2001 at 10:09:41PM -0700, Justin Erenkrantz wrote:
> 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)?

We are going to have a misc/ directory which will contain version checking
stuff. I'd be okay with it in there (+1), but am also happy with a new
directory (-0). The other directories have "bulk" or potential for it, so
they make some sense. But "date"? I can't see much going in there.

> 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.

mod_dav_fs also has some date formatting functions in dav/fs/repos.c that
I'd like to see migrated.

> 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.

MD5 is actually very good at creating random data. A one bit change in the
source produces unknown changes in the output. And it isn't reversible. The
technique works well.

However, that was simply a "crap. don't have nice random stuff. let's do
<this>" approach. The UUID stuff doesn't *truly* need a cryptographic random
number, but "good" numbers are needed. (I forget the exact details; would
need to read the UUID spec again)

> 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

Your gut is correct :-)  The plan has been to move the MD5 code from APR to
APRUTIL/crypto/. We also have the SHA1 cryptographic hashing function in
that directory right now.

(note that apr_getpass needs to move also, once we export an apr_crypt()

> 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.

Well, you could skip the PRNG and just use "decent" random stuff in
getuuid.c. Or go whole hog. Your call. I'm perfectly fine with a portable

> 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

Your call on the PRNG stuff.

The MD5 can easily move, and you can substitute some other random
constructions. See the notes in:


section 4 for why I used the MD5 stuff. Note that it just asks for "suitably
random" information for the node ID, and then suggests that MD5 or SHA1 can
be useful.

For example, just copying the hashing function from apr_hash.c should be
quite fine.

(and all that is irrelevant if you add a PRNG)


Greg Stein, http://www.lyra.org/

View raw message