httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Thorpe <>
Subject Re: cvs commit: httpd-2.0/modules/ssl ...
Date Tue, 27 May 2003 20:12:44 GMT
Hi there,

On May 27, 2003 01:17 pm, William A. Rowe, Jr. wrote:
> At 02:46 PM 5/25/2003, Geoff Thorpe wrote:
> >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.

Ah, perhaps I am mistaken then - my understanding had been that RSA had 
submitted patches to Ralf for inclusion in mod_ssl (back before apache-2 
factored into things). Even so, considering the Covalent angle I can see 
that there may have been more than one effort underway anyhow. Whatever 
the exact history, I certainly meant no offense.

> 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.)

Sure, I think the effort involved is pretty self-evident. I was merely 
suggesting that perhaps RSA could be convinced to invest some of their 
own resources to tweaking and testing the SSL-C integration. After all, 
can you point me to a more widely installed SSL/TLS-enabled server 
application than Apache? Read: "you are (or would appear to be) a large 
part of their market". My own interest in the ssl configuration didn't 
strictly come from my involvement in openssl, but rather the hacking I 
was doing on apache-2 integration with distcache. However, when I saw 
that some work on the general ssl/tls configuration was needed, it was 
pretty obvious to me that the best thing to do is grab the bull by the 
horns. Maybe RSA don't care, or maybe they do care but don't want to get 
involved, but both would be hard to imagine under the circumstances. BTW: 
I wasn't trying to dismiss the efforts of you, Doug, Madhu, nor anyone 
else. On the contrary, I think your jobs have been (and will continue to 
be) decidedly tricky in ways they needn't be if those on the "inside" of 
the SSL-C code contributed their own know-how. Just covering the 
backwards-compatibility problems must be a nightmare and this is 
presumably something "they" could sort out quite trivially.

But hey, I'm the last guy who wants to advance SSL-C's cause, so I'll 
leave it there. :-)

> >> 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 :-)

Pleasure. :-)

> >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.)

It's possiby a trivial change, and equally possibly a nightmare. BTW: Does 
this problem crop up with any other modules? Ie. do other modules have 
linker dependencies that are satisfied implicitly by apr? If so, they 
must surely face similar issues if they attempt to do any autoconf checks 
during configuration (and in which case, the issue of re-ordering the 
configuration system would solve a class of problems greater than just 
those of modssl).

Actually continuing on that line of thinking, there's an orthogonal 
cleanup I could suggest, but one that might make later rearrangements 
less confusing; is it worth moving the SSL-specific M4 code out of the 
top-level and into modules/ssl/config.m4? This seems to be one of the 
ways in which the ssl module is (perhaps needlessly) unique in the way it 
is wired up to the rest of the tree. Just junk-food for thought.

> >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.

Sure, though this case was slightly misleading because there were other 
rational reasons for why those checks might have been there, and that's 
partly the reason why I didn't notice the *other* reason for their 
existence. Of course, laziness/carelessness played its part too, as 
you've observed. <gulp> If it's any consolation, I am now more painfully 
aware of SSL-C implications than I would have ever chosen to be. :-)

> 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.

Yep, if apache2+modules/ssl compiles and links today, then pkgconfig can't 
give us anything we don't already have - though it is certainly a wise 
idea for solidifying the code for later.

> >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.

I'll (mostly) hold my tongue - all I'll let slip is that I wrote 
ENGINE_init() and can imagine ways in which it could one-day be NOP'd out 
of existence. Of course, even if those possibilities did eventuate to be 
the "Right Way" forward for openssl, my current schedule puts them easily 
out of the reckoning for this decade at least...


Geoff Thorpe

View raw message