apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david reid <da...@jetnet.co.uk>
Subject Re: [PROPOSAL/PATCH] add ssl sockets
Date Wed, 14 Jun 2006 08:26:35 GMT
William A. Rowe, Jr. wrote:
> Garrett Rooney wrote:
>> On 6/13/06, david reid <david@jetnet.co.uk> wrote:
>>> The attached patch is a first pass at getting some support for using
>>> openssl directly for ssl sockets within APR. I've tried to be generic in
>>> the basic configure code, but the actaul guts are basically openssl
>>> related.
>>> Disclaimer - this is based on some code I had written a while back and
>>> never really gotten finished, so this has a lot of it's flaws and
>>> unfinished feeling. It does however show the approach I've been taking.
>>> There isn't even documentation yet!
>>> What's attached isn't anywhere near finished or even heavily tested, but
>>> it works as far as it has been tested and at least will (hopefully) spur
>>> some discussion about
>>>  - whether this is desired
>>>  - whether this is the right way to do it (other methods are apparent)
> I'm doing some similar work, not for sockets, but to scratch apr's
> implementation of hashing, etc from the library.  Your ssl detection looks
> great, I'd much rather see this layer in apr-util (and perhaps a apr-helper
> lib of it's own) rather than apr core.  It happens to be the same place my
> ssl detection code lives.  I'm working on mine for FIPS-140 work.

why not in core?

> I'm thinking the most interesting person to ask on this is Brad Nicholes
> who
> implemented a trivial ssl layer using the ssl-enabled sockets.  Obivously
> whatever we do, it should be basic enough that he can implement this
> without
> even loading a crypto library.  Likewise Temme works at britestream, and
> their
> and similar hardware can do this with a couple library calls, and use the
> tcp/ip api.  All of these could be abstracted through your proposed
> interface.
> In principal, +1!

Very true.

>>> I think it's something we should have and it's something I'll likely
>>> persue, but I would like it to be in the main tree of apr-util. I'm not
>>> proposing that what's included be submitted directly, but if this is the
>>> approach then it'll give a starter for people to hack about.
>>> With that background, here is the code... I'm away from tomorrow until
>>> Friday, so don't be offended if i don't reply...
>> I think this would be great stuff to have around, but if possible I'd
>> like to avoid having an entire separate ssl socket type that parallels
>> the regular APR socket.  If we could have the ssl functions return a
>> socket that knew how to do the SSL parts under the hood, that would be
>> great...
> In general I would like to avoid overloading too many indirections, and
> it's
> certainly too complex to implement in one generic apr_socket_create.
> But for read/write/poll, I'd like to see how painlessly we could implement
> this.
> Moreso, I'd like to see if we can ensure there is only one apr
> read/write/poll
> sort of operation across all apr entities.  Even if it needs to be
> something
> like apr_generic_read() (fugly name, sue me).
> This work is on the right track, that's for sure.  Let me look at
> blending our
> two ssl detection stubs together (damn wish I was paying attention and
> could
> have spared you reimplementing, sorry :(  )

Didn't take long :-)


View raw message