httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: location of md5, sha1, base64, and validate_password
Date Mon, 08 May 2000 15:06:55 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, May 08, 2000 8:37 AM
> 
> Nobody is talking about ap.lib. These things could just as well go into
> ApacheCore.dll (and should, IMO). And yes, ap.lib should die and that
> stuff would just go into src/main.

Glad we are on the same page here :-)

> Ronald points out that the md5/sha1/base64 functions have no more
> system-specific code in them (they layer on top of APR). 
> Therefore, they don't need to go into APR.

Short of EBCDIC, I do agree.

> This question goes back to whether APR is to enhance 
> portability, or if it is a catch-all kitchen sink of useful 
> functionality. (and by my phrasing, you should be able to 
> tell which I prefer... :-)

Here's my understanding of the -ORIGINAL- APR goal...

Create a single, portable Apache library for fundimental Apache
application functions.  Note, this is not the singular Apache Server,
but the family of applications from the Apache Software Foundation.

I would expand on that to imply that APR is the host of process,
threading, memory and file management that is constantly assaulted
by incompatibility between platforms.  But I extend that to include
tcpip/internet -centric functionality.  My last argument (and last
comment on this subject) is that I see many apps that the Apache
Foundation would sponsor require md5.  sha1?  You've got me there.

I saw and agreed with the vision of a cross-application support
library.  If these are useful to other ASF projects (that don't
otherwise depend on linking into the Apache core library), roll 
them into APR.  If not, toss them back to the Apache-httpd core app.

Bill

> Cheers,
> -g
> 
> On Mon, 8 May 2000, William A. Rowe, Jr. wrote:
> > I think the answer is blatently obvious...
> > 
> > ap.lib is dead.  Three modules... one (ap_hooks) not terribly 
> > portable from library to library within Win32:
> > 
> > ap_hooks -> apache's core (src/main), perhaps as util_hooks.
> > 
> > It is simply too application specific to Apache.
> > 
> > ap_sha1 / ap_base64 -> apr
> > 
> > This is truly generic code.  There are (mostly charset) portability
> > issues with this module, e.g. EBCDIC.  That makes them appropriate
> > to apr, if I'm not mistaken.  I agree sha1 *isn't* a very generic
> > function, so I wouldn't mind seeing it in the apache core 
> (src/main).
> > 
> > There is nothing else left in ap.lib... why on earth would we
> > move anything to it :-)  I'm in agreement with Ryan's original 
> > choice to move ap_md5 to apr, and these choices follow logically.
> > 
> > Time to kill it?
> > 
> > Bill
> > 
> > > -----Original Message-----
> > > From: Life is hard, and then you die [mailto:ronald@innovation.ch]
> > > Sent: Sunday, May 07, 2000 8:52 PM
> > > To: new-httpd@apache.org
> > > Subject: location of md5, sha1, base64, and validate_password
> > > 
> > > 
> > > 
> > > I hate to bring up old discussions again, but I don't recall any
> > > satisfactory resolution.
> > > 
> > > Currently we have md5 and validate_password in apr, and sha1 and
> > > base64 in ap. To bring validate_password up to date it needs
> > > access to both sha1 and base64 (this is for Netscape's algorithm).
> > > Apart from that, having md5 and sha1 in different parts is just
> > > stupid.
> > > 
> > > Also note that nothing in apr depends on md5 on validate_password.
> > > And now that we have the ap_xlate stuff none of the involved
> > > functions have any system specific code in them (unless
> > > ap_MD5InitEBCDIC is meant to be called by something in apr).
> > > 
> > > So, we need a resolution: either we move md5 and validate_password
> > > back to ap, or we move sha1 and base64 to apr.
> > > 
> > > Votes?
> > > 
> > > Which ever way, I'll do the changes.
> > > 
> > > 
> > >   Cheers,
> > > 
> > >   Ronald
> > > 
> > 
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 

Mime
View raw message