William A. Rowe, Jr. wrote: > 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.
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 :-) david
