Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of justin.erenkrantz@gmail.com
 designates 66.249.92.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Xs7PQEy6kUF8z/fqXGvSINwRE1bORnPjGMUvSJ046wokWo/sXhBahQWRCVCFZQxtS4tDoVqtRgiHhKCgYJ2Be+0ygZ6A8MlEY6Cly+52PuBwZNnM0Gl6IH5Gifll7gTjc3kPKbCbbTbvGgzb/NdZpRI0pxO0i7FR0CUc2dvOf4k=
Message-ID: <5c902b9e0701030829w5457ac81hd818370259de2b49@mail.gmail.com>
Date: Wed, 3 Jan 2007 08:29:54 -0800
From: "Justin Erenkrantz" <justin@erenkrantz.com>
Sender: justin.erenkrantz@gmail.com
To: dev@apr.apache.org
Subject: Re: [PATCH] Optimized MD5 implementation from OpenSSL
In-Reply-To: <20070103103050.GA10268@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070102220102.GB3226@bourbon.ics.uci.edu>
	 <20070103103050.GA10268@redhat.com>

On 1/3/07, Joe Orton <jorton@redhat.com> wrote:
> This would need to have some severe future-proofing to be safe against
> any change to MD5_CTX in future versions of OpenSSL, e.g. only using it
> for the specific sizeof() that structure as currently defined.  (that
> would cover the cases where MD5_LONG is currently not 32-bit too)

Well, I think the 'right' solution may be to deploy a new MD5 API that
takes a pool and we can dynamically allocate the MD5_CTX rather than
asking the client to allocate it off the stack.

Basically, change apr_md5_init() to:

APU_DECLARE(apr_status_t) apr_md5_init(apr_md5_ctx_t **context,
apr_pool_t *pool);

combined with making apr_md5_ctx_t an opaque structure.

If we change its signature, I don't know what we want to do - do we
follow Subversion's example and use 'apr_md5_init2' and friends?  Or,
should we open the flood gates for APR 2.0?

> 1. is having an ENOTIMPL _set_xlate really an excusable regression?

Yes.  We already do that for !APR_HAS_XLATE case, so callers need to
handle that anyway.

> 2. is it intended that the return values from the OpenSSL MD5_*
> functions are ignored?  (can those functions even use the OpenSSL error
> stack and all the mess that entails?)

My look through those functions doesn't indicate any error returns -
just like our own implementation, FWIW.

> 3. does this mean that apr_md5_* can only be guaranteed to work after
> apu_ssl_init() has been called?

AFAICT, looking at the source code, the OpenSSL MD5 code doesn't use
any of the OpenSSL error stack or functions.  (It doesn't use any
errors.)  So, it shouldn't depend on apu_ssl_init() being called
first.  -- justin