httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Thorpe <ge...@geoffthorpe.net>
Subject Re: [PATCH] openssl configuration
Date Thu, 27 Feb 2003 21:11:55 GMT
Hi Madhu,

* MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) (madhusudan_mathihalli@hp.com) wrote:
> I haven't gone through the entire stuff, but some quick questions, based on
> your patch :

Thanks for the initial feedback, it's certainly useful to know this code
has been on other people's minds, and that I didn't just stumble onto
something old and forgotten.

> 1. I thought we should not be enforcing openssl version number checks
> (something like - openssl version SHOULD be > 0.9.6i) - mainly because ppl.
> can apply patches to their previous versions of OpenSSL, and thus avoid
> security problems.. (ofcourse, I know you're coming from the OpenSSL
> background, but that was the message I got here when I tried doing something
> like that)

I put the version checks in simply because there are version checks in
the existing M4 stuff and I would have thought it unacceptable to the
ASF for me to remove them! :-) The current version checks are
implemented in a cock-eyed fashion and are also out of date (0.9.6e used
to be a meaningful cut-off point, but that has changed more recently).

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". This
way, the more determined users can force configure to bypass that,
whilst it still provides a certain safety-net for the more naive and
less intrepid against accidently meddling with known-to-be-out-of-date
support libraries.

> 2. Regarding hardcoding "openssl/some_header_name.h", I think it's a bad
> idea - how about ppl. who want to use other SSL toolkits along with apache
> ?. 

Erm, like what? The only candidate I can think of would be the RSA-C
toolkit? If so, I would say that it doesn't make much sense to try and
deliberately reduce the focus (or increase the blur, if you prefer) of
the configuration checking so that something other than openssl still
slips through the configuration looking like openssl. The complexity
doesn't seem worth the trouble to me.

To support other SSL toolkits, the more sensible approach would be to
introduce alternative autoconf checks that are tailored to those
toolkits. But anyway, I find it difficult to imagine that the existing
version checks in Apache's configure was letting through alternative
toolkits anyway?? So perhaps something like "--with-rsa-c" could be
implemented, and it would be able to target RSA-C directly without
needing to be fudged to only check things common to both RSA-C and
OpenSSL. 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). The more things go, the more
OpenSSL and RSA-C are likely to diverge - I strongly suspect they've
already diverged too far for the code in its current form, but perhaps
I'm mistaken there. If the only issue right now between the two is what
prefix we do or don't add to the include paths, then that should be
considered extremely good fortune. Sooner or later though, we'd end up
needing to separating things with precompiler logic to handle
differences between toolkits, syntax, symbol definitions, enhancements,
optional extras, etc. Failing to do that in the autoconf support or the
SSL/TLS module code puts Apache in a position of being dependant on two
entirely independant development projects remaining "similar enough".
That's not a solid position to maintain, and you lose any ability to
tune to (or benefit from) a toolkit's evolution. It also goes against
the grain of why things like autoconf exist.

Of course, I'm hardly about to donate hours or days of my own time to
further RSA's commercial cause. :-) But if doing some re-organisation
work will benefit apache and openssl as well, I wouldn't begrudge
helping create targetted support mechanisms for both OpenSSL and RSA-C.
It certainly seems a better way to go than taking a hands-off approach
to the use of fork()d toolkits - nobody can give Apache or its users any
guarantees that they'll be able to rely on continued similarities. Or
were you referring to SSLeay? Or compability layers built on top of
something else?

Cheers,
Geoff

-- 
Geoff Thorpe
geoff@geoffthorpe.net
http://www.geoffthorpe.net/


Mime
View raw message