httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <>
Subject Re: hooks
Date Wed, 05 Jul 2000 20:12:21 GMT
On Tue, Jul 04, 2000 at 05:10:26PM -0700, wrote:
> > > I would still really like to see all of these files in APR.  They all use
> > > APR types, and although the code is all common for all platforms, they are
> > > portability issues for most programs.  By moving them into different
> > > directories within APR, we can enable and disable them at compile time.
> > 
> > What portability issues? The ebcdic stuff is now in apr (ap_xlate, or so
> > I assume), and I can't think of any others.
> The EBCDIC stuff is still in ap_base64.c, but that is another issue.

That has to change anyway to use ap_xlate.

> I was mainly thinking of the MD5 stuff with regards to portability,
> because some platforms have it and others don't.  We actually took our
> code from FreeBSD, so we know they have this function.  

As has been said, these are completely portable functions across any
platform/compiler/etc, with the exception of the non-binary versions
of update - those need to use ap_xlate, at which point the stuff
becomes fully portable.

Btw., does anybody disagree with changing the update functions in
md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
reflect which are ascii and which binary (the ascii forms first
translate the characters as necessary to ascii). And similarly
for ap_base64. Currently we have ap_SHA1Update() and
ap_SHA1Update_binary() in 1.3.

> The other argument is that this is a bunch of VERY portable encryption
> code.  Anybody who is trying to write a secure piece of portable software
> would most likely like to use some of these functions.  Isn't this what
> APR is supposed to provide?  The ability to write very portable software
> with one library.  We can put all of these functions in lib/apr/encrypt or
> lib/apr/enocde (may be more precise) and be able to enable/disable them at
> compile time.  I really think these are useful portable routines.

I agree. This is boiling down to the previous (and I think undecided)
discussion of what should go into APR. I have nothing against putting
md5, sha1, and base64 into APR - I'm just noting that I think your
portability argument isn't valid.

> > > At the very least getpass is a portability issue, and it doesn't always
> > > have common code, so it definately belongs in APR.
> > 
> > Sorry, confused getpass with checkpass (which needs to be brought in from
> > apache-1.3) - you're right, getpass shouldn't be touched.
> ap_checkpass is validate_password, which can be found in
> apr/lib/apr_md5.c.  :-)  See above for why this function shouldn't be
> moved out of APR.  It should be moved to apr/encode/apr_validate.c IMHO
> though.

I quite aware of what ap_checkpass contains :-)
A number of changes were made in the 1.3 code base last July, but those
changes never got brought forward to 2.0 (the snapshot was taken just
before). As part of the move I intended to bring those changes forward.
Btw., apr_validate.c is too generic, IMHO - validate what?
apr_checkpass.c is clearer. Or apr_validate_pw.c . But that's a nit.



View raw message