httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: httpd-2.0/modules/ssl ...
Date Tue, 27 May 2003 17:17:25 GMT
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 


Mime
View raw message