At 02:46 PM 5/25/2003, Geoff Thorpe wrote: >On May 24, 2003 09:38 am, William A. Rowe, Jr. wrote: >> Well, in the SSLC case, HAVE_SSL_SET_STATE was required because >> you can't even renegotiate without toggling the state. I tried a >> pretty simple hack, replacing the set state code (which on OpenSSL is >> simply a bit tweak into what should be opaque data) with the >> SSL_renegotate() function across toolkits (with the patch applied to >> 2_0_BRANCH). >> >> That didn't work, as several of the perl-framework ssl/ tests started >> failing. Considering that SSL_set_state a source patch on top of the >> SSLC toolkit, and most SSLC users work from binary distributions, this >> was never clean in the first place. Since ApacheSSL uses the >> SSL_renegotiate() function, and it's support in both toolkits, this is >> the right direction, I just missed something important (which I will >> revisit as I find some cycles again.) > >OK, I can't say anything of much usefulness about SSL-C as I have no >experience with it. What I would suggest is that clean SSL-C support in >Apache2 may be useful to many people, but there are none who benefit from >it quite so much as RSA themselves. IIRC, it was from RSA that the >original mod_ssl tweaks for SSL-C originated
Excuse me? No... those have been the fruits of Doug MacEachern's, Madhu's and my own efforts. RSA has been helpful from a support perspective, but didn't actually port any code that *I* am aware of. > - so it begs the question; >are RSA involved in maintaining this code at all? It seems they should be >doing as much as possible to avoid bitrot in the SSL-C hooks, and they'd >be far better placed than anyone to make it happen (and test it)? The significant problem with mod_ssl's history is that the code reaches deep into the 'private', 'internals' of the library implementation. Ben Laurie, Madhu and I are refactoring the various bits that are too transparent into the guts of the library. It really should be the library's job to expose the appropriate interfaces... indeed they are in OpenSSL and SSL-C (somewhat differently in places.) But many of the appropriate 'methods' were introduced after they were first needed by mod_ssl, and that code was never refactored to approach the library cleanly. The problem from RSA's perspective is that they don't distribute mod_ssl, as far as I'm aware of, nor do they 'support' it. They support an SSL toolkit. Do whatever you will with it, and scream to them for negotiation bugs, or other toolkit operational or functional bugs. Covalent via Doug and myself, and HP via Madhu, have an interest in mod_ssl interoperating with the RSA toolkit, so all three of us have invested blood, sweat and tears to clean up some of the crufty stuff (occasionally introducing extra-crufty bits.) Hopefully others will grab their favorite toolkit and propose patches to extend the module. This isn't terribly compatible with the socket-based SSL approach, which is why Brad Nicholes had to deploy a different module for Netware. And though they are defined on Win32 (and supported on WinCE) the extended SSL WinSock foo is unimplemented (or generally not documented) across our Win32 supported platforms, so Win32 porters have gone the mod_ssl route. >> In any case, we won't 'HAVE' ENGINE_init if we don't inject ssl libs, >> so I don't have any problem moving those detection macros into the >> 'protected' reconfiguration. That still leaves me with the question of >> how we can test on a platform like solaris, where OpenSSL needs >> libraries like -lsocket just to perform a test compile of >> ENGINE_init(). > >Well this works inside the protected configuration for the reason that it >pulls in the apr linker flags, whatever they may be (eg. -ldl -lsocket >-lnsl [etc]). Ok, I see that now, and have committed the code to httpd-2.1 with all due credit to y'rself, thanks :-) >But the better solution is to re-arrange the configuration >order so the dependencies are already satisfied. No doubt, a project for another day (at least for my crazy schedule.) >> >But we cannot quit testing for the SSL_set_state sort of functions (I >> > don't know if you did or not) because I for one enjoy forcing SSL-C >> > to do what it should have done in the first place :-) Please don't >> > clobber function detection in your final patch, please! > >Well this certainly slipped through the cracks - apologies for my part, I >don't have SSL-C so I was largely flying blind in that respect. In the future, please grep -r "BOGUS_SYMBOL" * before you submit this sort of patch, it makes it alot easier to see what's out there. Then it's not so confusing to search the archives for the discussion of why on earth the code is out there. >> Perhaps we should go ahead and use the pkgconfig if it exists, or fall >> back on our own autoconfig if it doesn't. Would that be a win? > >Maybe, but I think elegance dictates that the first priority would be to >get the existing configuration steps ordered by dependency. The fact that >apache-2 compiles and links indicates that there are no missing linker >flags missing once the configuration has completed - it's only during >configuration itself that there are one or two moments when the state of >the flags can be left inconsistent. Later, if you then want to detect and >add some logic to pull flags out of openssl.pc (and/or any equivalent for >SSL-C), you could presumably use some macro to merge them in and catch >any necessary flags you might otherwise be missing. Right, but there still might be worthwhile information in the pkgconfig that we aren't aware of. I was mostly wondering what code is around to slurp out the useful details from the pkgconfig contents. In this case I agree, it seems we can keep plugging along. >> Now if you test HAVE_ENGINE_H, of course it will find engine.h. >> However, if you test compile for ENGINE_init, against -lssl, it will >> link against only the FIRST libssl and then try compiling for that >> function. It won't try binding to more than one of any given library! > >Well yes, but as I pointed out - if a future version redefines ENGINE_init >as a backward compatible macro (or simply removes it, heaven forbid) then >you're still going to hurt, whether the autoconf test fails or not. In >this case, it seems you want AC_TRY_LINK. But that's perhaps a bit >pedantic of me. I'll drop this one, your call :-) I can't see this being deprecated into a macro - there are no _init calls in the ssl toolkits that devolve to no-ops. One of the distinguishing features of _init functions (in general) is that they can be used to create hard ties to library packages (e.g. using dlopen/dlsym to 'acquire' some library package.) This is why ENGINE_init is possibly the safest named symbol to test. Bill
