httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <>
Subject RE: [PATCH] openssl configuration
Date Thu, 27 Feb 2003 05:44:54 GMT
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


-----Original Message-----
From: Geoff Thorpe
To: Apache Development List
Sent: 2/26/03 9:18 PM
Subject: [PATCH] openssl configuration


I'll be mailing back here at another time about my work on integrating
"distcache" ( 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.


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


View raw message