apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: apr-util, crypto and openssl
Date Thu, 07 Jun 2001 09:23:02 GMT
On Thu, Jun 07, 2001 at 01:09:28AM +0200, Sander Striker wrote:
> Hi all,
> As if we weren't having enough discussion on this list
> I'll throw in something else...
> Could we consider _removing_ all crypto related code
> from apr-util (and apr for that matter, since md5
> still lives there)?

Nope. Per the comments already provided. Many apps nowadays use MD5 and/or
SHA1 for various kinds of functions. They are useful in a huge variety of
tasks -- not just crypto. Since they are generic hashing functions, they can
be used as an excellent checksum or as a unique identifier for items.

> If the apr style api is the reason for the code being
> in there I will understand, but I'd suggest a separate
> apr-crypto library (which effectively would be a thin
> wrapper of openssl).

mod_tls and mod_ssl in the codebase are highly dependent upon OpenSSL. It
has been suggested they should be more flexible, and work against other
libraries (I don't know *what* those libraries are, tho). Doing this in APR
(plain, -util, or a new -crypto) would be quite neat.

I don't have a lot of thoughts on the matter, tho.

> Last reason for removing the code: it prevents requirements
> driven fools like me from sending in patches that duplicate
> other work :-) Ben assured me that openssl is extremely
> portable, so that can't be the issue.

Well, I'm already questioning the whole MD4 thing. I can see that Samba
needs it, but who else? I'm not entirely sure why we put that into APRUTIL
because I'm not sure who *else* might want to have it there.

Can anybody name one or two other apps that use MD4?

> PS. I do have a crc32 patch laying about (isn't in openssl
>     or apr(-util) and it is pretty generic. I think it has
>     some use in projects other than ours, but I'm not sure).
>     Interested?

I haven't seen a need for it, so no. I'd prefer to at least have some
*requirements* for stuff like this. And preferably from more than one


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

View raw message