You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Klaus Wagner <kl...@it-austria.net> on 2006/08/16 12:57:07 UTC

Regex encap. but not SSL?

On Mon, 2006-08-14 at 16:48 +0100, david reid wrote:

> I've heard this a couple of times now, so while I had thought the
> benefits spoke for themselves maybe they don't.

As the regex encap. thread flames up I would like to know
if anyone ever intended to encap. SSL Libraries in apr-util.

The benefits would be far greater. gnutls and openssl could be
included - maybe even microsofts crypto api. this would raise
abilities for a) applications and b) httpd greatly which by now only
supports openssl (if my understanding is correct).

Openssl from a users view is quite hard to handle. There are several
ways to initialize ciphers wrong, mess up the code with BIO structures
and it gets even worse if nonblocking IO comes in.

So the main benefit would be simplification and abstraction from BIO
structures, beside the ability of using different backends.

I know that this task would be complicated and I don't know if all
crypto implementations have at least some similar functionalities
that can be wrapped.

regards klaus



Re: Regex encap. but not SSL?

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/16/06, Klaus Wagner <kl...@it-austria.net> wrote:
> On Mon, 2006-08-14 at 16:48 +0100, david reid wrote:
>
> > I've heard this a couple of times now, so while I had thought the
> > benefits spoke for themselves maybe they don't.
>
> As the regex encap. thread flames up I would like to know
> if anyone ever intended to encap. SSL Libraries in apr-util.
>
> The benefits would be far greater. gnutls and openssl could be
> included - maybe even microsofts crypto api. this would raise
> abilities for a) applications and b) httpd greatly which by now only
> supports openssl (if my understanding is correct).
>
> Openssl from a users view is quite hard to handle. There are several
> ways to initialize ciphers wrong, mess up the code with BIO structures
> and it gets even worse if nonblocking IO comes in.
>
> So the main benefit would be simplification and abstraction from BIO
> structures, beside the ability of using different backends.
>
> I know that this task would be complicated and I don't know if all
> crypto implementations have at least some similar functionalities
> that can be wrapped.

Initial implementations of ssl code have already been committed to
apr-util's trunk.

-garrett