I haven't gone through the entire stuff, but some quick questions, based on your patch :
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) 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 ?. -Madhu -----Original Message----- From: Geoff Thorpe To: Apache Development List Sent: 2/26/03 9:18 PM Subject: [PATCH] openssl configuration Hi, I'll be mailing back here at another time about my work on integrating "distcache" (www.distcache.org) support into Apache 2. I first need to run a bunch of checks on my autoconf hooks into the Apache 2 build system though ... ... which leads nicely on to why I *am* posting now. The distcache exercise put me in direct contact with the openssl checks in apache (acinclude.m4 + modules/ssl/config.m4), and so I noticed that the code had been waiting in a very strange state for someone to find time to sort it out. so I've been hacking away at it and have attached a (unified) diff of where I'm at. This isn't ready for CVS yet, but it needs (now) the input of an apache hacker to verify a few things and fix an issue to do with how the rest of the build system is tied together. Also, given some of the weirdness of the existing code, any "Right Way" of doing things is necessarily going to be a big enough change that regressions have to be watched for. Eg. the existing openssl checks just cycle through some preset commonly-used system paths, and don't use any of the normal autoconf mechanisms to find or test anything. It's obviously not supposed to be this way, but I can't guess how disruptive it might be to suddenly commit a correction to it. Well I'll leave off by logging some info about the patch contents. Any and all feedback would most welcome. Cheers, Geoff Patch notes: - I've left the existing APACHE_CHECK_SSL_TOOLKIT implementation but simply renamed it out of the way - this is mainly to make sure the diff is nice and clean and not an abomination caused by diffing two *almost* entirely different blocks of code against one another. - All the hard-coded path checking (where on earth did that come from?) that was used before is gone and the autoconf macros AC_TRY_COMPILE and AC_TRY_LINK are used instead to verify headers and libraries. This needs a regression once-over, but can't possibly be a good thing to leave the way it was. - The existing implementation doesn't try any compile or link tests, because right now any linking test would fail because the basic system library checks hadn't been performed in advance. I've put a FIXME there so someone can take a look at the issue - whatever Apache's existing library checks are is obviously sufficient, because Apache links :-) So it's just a matter of rearranging or reproducing all the standard -ldl -lnsl -lsocket [etc] checks to occur before APACHE_CHECK_SSL_TOOLKIT runs. - Relative paths to "--with-ssl" were broken but now work. Before they would pass the configure checks if the paths were valid relative to the top-level directory, but would then fail (not surprisingly) when compiling inside modules/ssl/. Linking was also broken for the same reason. - A path supplied to "--with-ssl" might (before) have been overriden by another linker path containing openssl libraries and yet silently succeeded. This can lead to mismatches between headers and libraries (with all the obvious linker or run-time problems that can lead to), and also has the failing that it succeeds whilst contradicting what was asked for. This can be pretty painful if there are important reasons why --with-ssl was specifying a specific build. - --with-ssl supports both installation bases (where include and lib are subdirectories) as well as compiled openssl source trees (just the lib subdirectory). I think this was the case before too, but because of the other items mentioned, this now actually works. - "openssl version" isn't used any more, because it requires that the openssl binary be installed. More accurate (and much easier) version checking is possible from openssl's "opensslv.h" header, and this has the added advantage that RPM type systems only need the "libopenssl***" package installed rather than the utils as well. - The version check is less fragile (no regexp string games) and has been bumped to 0.9.6i from 0.9.6e because of the recent SSL/TLS vulnerability. - openssl headers are now included with the "openssl/" directory prefix. - modules/ssl/config.m4 no longer needs to check SSL_set_state and SSL_set_cert_store functions - the only possible use for these was because nothing up until that point had run any compiler or link tests on the guesses made by configure. That's now changed so these checks are pointless. -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ <<openssl-conf.diff>>
