Hi Madhu,
* MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) ([EMAIL PROTECTED]) wrote:
>
> I agree that the current check is out-of-place, and it has to be changed.
> But, your proposal of error'ing out based on version number is what
> concerned me. Think of ppl. who've patched their sources with the fixes ?.
> You don't want to be rejecting the toolkit based on the version number
> available in the header file. I got a lot of push-back (locally also) for
> proposing something like that. But, having said that, I don't know of a
> better method of informing the users.
It seems the only commentary I'm getting is this same thing so it has
the feel of consensus to me. Can I have suggestions please for two
version thresholds - one to be considered a minimum below which
configure should fail, and another which should be considered a
recommendation below which configure should emit warning text. The
existing configure.in (IIRC) errors out below 0.9.6e, in case that's
useful as a guide.
> >It would perhaps make sense to provide a "--force-ssl-ver" type of
> >option that would bypass version checks, and then have any version
> >checking failure text point out the existence of "--force-ssl-ver".
> [SNIP]
>
> I like that.. If ppl. don't care what version of openssl they use, force
> them to move to the latest.. For others, they can always use the
> --force-ssl-ver flag. Does anybody else have comments ?.
Thom did, and if your previous efforts met with resistance that would
probably suggest there'll be others too. Perhaps the sense needs to be
reversed such than a "--strict-ssl-ver" flag can be used to force strict
version checking, otherwise a "softer" approach is taken by default. I
don't particularly care, I'd just like to get it to an acceptable level
so that the existing stuff can be replaced. The version check is not my
focus at all.
> [SNIP]
> >Erm, like what? The only candidate I can think of would be the RSA-C
> >toolkit? ...
> >The complexity doesn't seem worth the trouble to me.
>
> Well, I actually went through the whole process of trying to get apache +
> mod_ssl working with RSA toolkit :) [I just haven't been able to put it
> to-gether and submit a patch].
> Although I realize that lots of ppl. are moving towards OpenSSL, I believe
> there are ppl out there who'd like to have a alternative to the OpenSSL kit.
> Think about having better SSL performance, the RSA toolkit performs better
> than OpenSSL toolkit [no bad feelings].. By introducing openssl specific
> stuff, we'd be making it more difficult to use mod_ssl (+ Apache) with any
> other kits. BUT, if ppl on the httpd-community think different, I have no
> problems to make mod_ssl be more OpenSSL friendly..
>
>
> >To support other SSL toolkits, the more sensible approach would be to
> >introduce alternative autoconf checks that are tailored to those
> >toolkits.
> [SNIP]
>
> I find it easier to use the same options for both OpenSSL and RSA.. The
> autoconf can verify the existance of RSA specific header files, and realize
> that it's a RSA toolkit and not OpenSSL. But again, this is my personal
> opinion here.. I don't know what's the best option - any suggestions ?.
That's an option too, but either way I think the processing should fork
early on depending on the nature of the toolkit it finds. Ie. the
obvious trick to start with would be, inside the --with-ssl=<dir>
processing, to do something like;
if test -d $ap_ssltk_base/include/openssl
[process openssl checks, -D.. defines, and INCLUDE/LIBS/LDFLAGS
configuration]
elif test <some condition that identifies SSL-C> then
[processing SSL-C]
elif [etc]
else
AC_MSG_ERROR(What the hell does <dir> point to?)
fi
I still maintain my view that attempting to having one generic set of
tests and setups for OpenSSL, SSL-C, and anything else that implements
enough of a compatibility layer to get close to supporting modules/ssl/,
would be too loose-fitting and vulnerable to ongoing divergence.
> >Likewise, the includes in mod_ssl.h should be
> >#ifdef,#elif,#endif'd so that you get precisely the headers you need for
> >precisely the toolkit you are using (and using precisely the header
> >paths defined in the respective API).
>
> It's being done in the sources today (in ssl_toolkit_compat.h)
Ah, well then it's easier than I thought (I hadn't noticed
ssl_toolkit_compat.h). The OpenSSL includes should go in there because
that's precisely the place this sort of distinction can be handled.
Ie. in the "#ifdef OPENSSL_VERSION_NUMBER" section, we should include
those headers that OpenSSL itself should include to avoid all warnings,
support all available extensions, and use the correct "openssl/" path
prefix (this is not just aesthetics, it's *important* if the openssl
headers are installed and used from system-wide locations so that no
include munging is wanted or desired). Likewise, the SSL-C versions
could occur in that section of the header, and any divergence (other
than the path) between openssl and SSL-C will be handled there.
I can rejig my patch for this if there's agreement with the approach. I
assume the includes required for SSL-C match those that are in the
current mod_ssl.h?
> I don't know how many others have tried to do this, but based on my
> experience, most of the changes went into a header file.. There were very
> little modifications required to the .c files. However, I do echo your
> concern regarding how long will it be, before the two go in different ways.
> It might become more difficult to maintain one code base for supporting both
> the toolkits.
Well the approach in ssl_toolkit_compat.h looks good, I wish I'd spotted
it before (it shouldn't surprise you that I was more used to looking at
mod_ssl/apache-1.3 source so didn't expect to find that). As long as
compatiblity can be maintained merely by pre-compiler tricks and stub
functions/macros, then why not? I think the error is in trying to do
this transparently by trying to keep configure checks and source code
confined to areas of commonality between different toolkits. Those areas
will continue to shrink :-)
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
