Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@samba-tng.org>
To: <dev@apr.apache.org>
Subject: RE: [PATCH] apr-util hmac md5
Date: Tue, 5 Jun 2001 10:12:44 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOIEHFDPAA.striker@samba-tng.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20010605002951.C21860@ebuilt.com>
Importance: Normal

> On Tue, Jun 05, 2001 at 01:54:05AM +0200, Sander Striker wrote:
> > Hi,
> > 
> > This patch adds HMAC MD5 to apr-util.
> 
> Where would we use this?  Is this algorithm of sufficient usage that it
> would benefit being in apr-util?  I've never heard of HMAC before - I
> had to look it up on rfc-editor.org.  Maybe I live in a paper bag.

It is keyed MD5 :-)
Probably not in heavy use, but I'm gonna need it.

> I'd just like to make sure that someone is using this before it gets 
> committed.  I'd like to prevent feature creep (we're so beyond that 
> point).  Here's my line in the sand...  =)  I'll cast a -0 on this
> patch (I can do that, right?).
> 
> I guess the distinction between what we have in apr-util and what is in
> OpenSSL is that the code is *probably* more portable (IIRC, OpenSSL
> sort of works on Win32 - correct me if I'm wrong).  Sander, I think
> OpenSSL's portability *might* be an issue for you as you often use 
> Win32.  I don't use Win32 so I wouldn't know.

Well, I'm not that big a win32 fan :-). It's just that since I started
looking into apr(-util) I really liked the true portability of it. I must
admit that I didn't really look into OpenSSL that good to report on
portability issues. I just figured: hey, apr-util has got a crypto
directory, I'm missing some stuff that I'm going to need, so lets send
in a patch. I also have to say that I am not a big fan of having multiple
dependencies, if I can get away with just apr and apr-util I would be
very pleased. Also, I like the apr interface... Just my fl 0,02

> Personally, I'd defer to what Ralf and Ben have to say about this - I 
> think they both are on the APR lists (in case you don't know - they are
> also OpenSSL core members).  I think Ben posted a "What's up with this 
> crypto stuff?" message in the last day or so.  Well, *I* am not sure 
> how the crypto stuff fits in either.  So, time to get some feedback.

Ok, agreed. Btw, I'll be submitting patches along the way and I'd like
to see them make it into apr(-util). However, if the patches are denied
I have no problem in that, then I'll just move the code to my local
codebase. I'll just post what seems reusable, because I'm a bad judge
at that (in samba you encounter weird stuff of which you sometimes don't
know if someone else uses it).
 
> My $.02:
> 
> I would be inclined that the more popular stuff (md5 and sha1) be 
> included so that they are always present, but the more esoteric stuff 
> can stay in OpenSSL.  If you need those odd crypto functions, then you 
> need to figure out where OpenSSL is to link against, or start 
> submitting patches to them to get it to work.  I'm not sure that APR 
> needs to be a general purpose crypto library - OpenSSL does a decent 
> enough job as-is (from what I've been told).  Since OpenSSL is under 
> an Apache-style license, there shouldn't be any problem using their code.

I'll look into it.
 
> Thoughts?  *I* want to hold off on adding more crypto until I know what 
> others think and we have a coherent plan for crypto/.  Hence, my -0.
> I think that adding the link requirement of OpenSSL under all cases to 
> httpd will be troublesome (i.e. if we use OpenSSL for SHA1).  But, 
> when Ralf et al get around to cleaning up the mod_ssl/mod_tls stuff, 
> we might have a good way to detect/link against OpenSSL (so, we'd 
> remove crypto/ entirely from apr-util).  I'm not in a position to add 
> external build requirements.  That's a mighty big thing which needs to 
> be well thought out.

Ack.
 
>> PS. If someone is looking into MD5, maybe MD5_DIGESTSIZE can be 
>> changed to APR_MD5_DIGESTSIZE, like in the md4 code (which has 
>> APR_MD4_DIGESTSIZE).
> 
> Yeah, I should do that, shouldn't I?  One of these days...  -- justin

:-)

Sander