Garrett Rooney wrote:
On 6/13/06, david reid <[EMAIL PROTECTED]> 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.
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!
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 :( )
Bill
