changes

apach加密模块

      buffer?' messages occured in the past. The BIO callback function now
      only outputs messages for the actual read/write calls.

   *) Fixed a warning the `gcc -O -Wall ...' compiler flag combination causes.

   *) Fixed confusing terms in the final messages in mkcert.sh
      which display a short description of files under `make certificate'.

   *) Fixed compilation for SunOS where no RAND_MAX exists.

  Changes with mod_ssl 2.2.3 (05-Feb-1999 to 21-Feb-1999)
   
   *) Cleaned up the namespace of mod_ssl structures: 
      All helper structures are now named ssl_xxxx_t.

   *) Fixed hyperlinks to mod_log_config.html in mod_ssl's User Manual

   *) Let mod_log_config's %{XXXX}x functions (provided by mod_ssl) correctly
      expand to "-" instead of "" in case XXXX is not available as it's the
      case for other mod_log_config functions.

   *) Unbreak `SSLOptions +CompatEnvVar' by fixing two nasty bugs
      and adding a missing variable.

   *) Fixed a confusing "not"-typo in the FAQ.

   *) Another round to get rid of the core dumps under the DSO situation when
      DSOs are loaded to different memory addresses. We now no longer try to
      preserve `RSA *' and `X509 *' structures of the SSL library between
      Apache's init rounds. Because as we discovered, SSLeay/OpenSSL uses
      various static variables inside these structures which is a big NO-NO
      for the nasty Apache double-init round situation. Instead we now convert
      the internal structures to DER/ASN.1 byte-streams allocated inside
      mod_ssl's global memory pool. This now at least fixed the core dumps
      under the Solaris/DSO situation for me.

   *) Incorporated a few cleanups for the SDBM code Gred Stein sent me 
      while he was adding SDBM to his mod_dav package.
  
  Changes with mod_ssl 2.2.2 (04-Feb-1999 to 05-Feb-1999)

   *) Fixed `SSLOptions +FakeBasicAuth' and related stuff which
      was broken because of a typo in a context variable name.

   *) Fixed ToC in chapter 1 of the user manual.

   *) Fixed export lists src/ApacheCore.def (Win32) and 
      src/support/httpd.exp (AIX).

  Changes with mod_ssl 2.2.1 (27-Jan-1999 to 04-Feb-1999)

   *) Now the configure script uses bold mode to mark some
      error messages under xterm, vt100 and vt220 terminals.
   
   *) Added a new chapter 5 (`HowTo') to the User Manual where solutions for
      typical situations are presented.
    
   *) Now mod_ssl identifies itself to the SCCS `what' and RCS `ident'
      commands with a string `mod_ssl/2.2.x'.  This allows one for instance to
      quickly check what version a libssl.so by typing `what libssl.so' or
      `ident libssl.so'.

   *) Added a new directive `SSLProtocol' which is compatible to Stronghold
      2.x's directive of the same name. It provides a handy way to control the
      SSL protocol flavors (SSLv2, SSLv3, TLSv1) mod_ssl should provide on the
      server side. It's use is a little bit similar to special cases of
      SSLCipherSuite, but it actually directly affects internal behaviour of
      the SSL library. So, saying `SSLProtocol all -SSLv3 -TLSv1' to get a
      SSLv2 only server is not really equal to an `SSLCipherSuite' where just
      all SSLv3 and TLSv1 ciphers are dropped.
   
   *) EAPI functions are now also added to src/ApacheCore.def.
   
   *) Output a warning when `SSLVerifyClient require' is used but no CAs are
      configured for verification.  Additionally the `peer didn't return a
      certificate' message is annotated with a similar hint.

   *) Updated the README.dsov.{fig,ps} files to reflect the
      additional internal data structure link from SSL* to request_rec*.

  Changes with mod_ssl 2.2.0 (21-Jan-1999 to 27-Jan-1999)

   *) Commit the long-prepared and long-awaited feature of 
      per-directory SSL configuration parameters. 
      
      The background is this: SSL parameters like the Cipher Suite or the
      certificate chain verification parameters up to now could only be
      configured on a per-(virtual)server basis and this way apply to all URLs
      under https://this-virtual-server/.  The drawback is obvious: You've to
      find a common denominator for the whole website which isn't usually
      possible. For instance just because you need client authentication
      (``SSLVerifyClient require'') for https://this-virtual-server/foo/bar/,
      this shouldn't mean you have to force client authentication for the
      whole server. Same for ciphers: Just because a subarea needs to enforce
      a stronger cipher (e.g. no export, no null cipher, etc.) shouldn't mean
      that the whole website can only be visited with those requirements.  So
      the idea is to enforce those (usually stronger) requirements on a
      per-directory basis.

      The problem is: It's a chicken and egg situation. To decide which
      parameters should be enforced in the SSL handshake mod_ssl has first to
      find out the requested directory. For this the HTTP request has to be
      read. But for this the SSL handshake first has to be performed. Bingo!
      
      The nifty solution known from Netscape Commerce servers now is: We
      simply do the standard SSL handshake, then we read the HTTP response,
      then we perhaps reconfigure the parameters and enforce a second SSL
      handshake (this is called "SSL renegotiation") with it. And only when
      this handshake is also successful, the HTTP response is send.

      How is this configured? You just put additional SSLVerifyClient,
      SSLVerifyDepth and/or SSLCipherSuite directives in <Directory> or
      <Location> containers or even .htaccess files. When Apache reaches those
      directories, those directives reconfigure the SSL parameters and the SSL
      renegotation is automatically enforced by mod_ssl. The only drawback is
      that although an optimization is done to reduce unnecessary
      renegotiations (when the parameters were not actually changed), you
      usually increase the overhead for a request because a SSL renegotiation
      is expensive. So, use the per-directory reconfiguration feature
      economically.

      Under SSL_EXPERIMENTAL additionally the directives SSLCACertificatePath
      and SSLCACertificateFile can be used in per-directory context for
      reconfiguration. But it's tagged experimental because SSLeay/OpenSSL
      still lacks real support for this. So an ugly kludge has to be done to
      support these two directives, too.
      
   *) Give out more information on "Certificate Chain too long" error message.

   *) Moved SSLeay/OpenSSL specific stuff to the new source files
      ssl_util_ssl.[ch]. !! ATTENTION: NOW SSLeay 0.9.0 or OpenSSL IS NEEDED
      !!  Because the new internal structures need at least SSL_get_ex_data()
      and SSL_set_ex_data() and those are not supported in SSLeay 0.8.x.  So
      we removed all remaining support for SSLeay 0.8.0. OTOH that's no
      problem, because SSLeay 0.8.x is known to be unstable, so it's
      reasonable to remove support for it also for other reasons.

   *) Added a second SSL context variable which holds (with a delay) a pointer
      back to the request_rec structure in Apache.  This is needed to reach
      the per-directory configuration parameters.
   
   *) Updated the User Manual for mod_ssl 2.2

   *) Added SSL_EXPERIMENTAL rule to Configuration.tmpl which
      can be used to enable (APACI: ``--enable-rule=SSL_EXPERIMENTAL'')
      experimental code inside mod_ssl. Code is declared experimental unless
      it is proofed to be stable by the users.

   *) Replaced the GNU Bison generated ssl_expr_parse.[ch] files with variants
      generated by BSD Yacc. This way we have more portable source because BSD
      Yacc doesn't used alloca() and other tricks. This especially should
      solve the problems under HP/UX.

   *) Updated INSTALL file for recent changes and fixed a few typos there.

   *) Add a SSL_SDBM rule to Apache's Configuration.tmpl which can be used
      (APACI: ``--enable-rule=SSL_SDBM'') to force mod_ssl to built with the
      built-in SDBM instead of the custom defined (DBM_LIB) or vendor supplied
      DBM library. This is especially useful when the vendor DBM library is
      buggy or restricts the data size too dramatically (BTW, Berkeley-DB/1.x,
      Berkely-DB/2.x and GDBM based DBM libraries are ok, because they allow
      unlimited data size).
   
   *) Enlarge the SDBM pag/dir blocksize from 1KB/4KB to 8KB/32KB to make sure
      SDBM really can deal with SSL sessions containing long certificate
      chains. !! ATTENTION: THIS MEANS THAT YOU'VE TO ONCE REMOVE THE FILE YOU
      CONFIGURED WITH SSLSessioCache WHEN SDBM WAS USED AND YOU UPGRADE TO
      THIS OR A LATER mod_ssl VERSION, BECAUSE THE INTERNAL LAYOUT CHANGED. SO
      THE FILE HAS TO BE RECREATED WITH THE NEW LAYOUT !!

   *) Make the DBM based session cache more robust by using additional error
      situations. This should fix some observed core dumps on Linux boxes
      where the vendor DBM library returned strange values.

   *) Fixed configuration handling for global directives: Now the correct
      memory pools are used and after the first configuration round the global
      configuration structure is locked.

   *) Added a new `SSLRandomSeed' directive for explicit seeding the Pseudo
      Random Number Generator (PRNG) of the SSL library on server startup
      and/or connection establishment time. The intent is that this way the
      PRNG is better initialized and this way the security of the generated
      SSL protocol ingredients are more secure (because less predictable). For
      maximum flexibility you can use three seed sources: an internal source,
      an external file or an an external program. And you can specify one or
      more such sources, of course. For instance under a FreeBSD box you can
      now use the following: 

          SSLRandomSeed startup builtin
          SSLRandomSeed startup exec:bin/truerand 16
          SSLRandomSeed startup file:/dev/random  512
          SSLRandomSeed startup file:/dev/urandom 512
          SSLRandomSeed connect builtin
          SSLRandomSeed connect file:/dev/random  512
          SSLRandomSeed connect file:/dev/urandom 512

      This would at server startup-time seed the PRNG first with a few bytes
      from the internal source, plus 16 bytes read from stdout of the
      `truerand' utility (which is based on the AT&T truerand library and can
      be found in the mod_ssl distribution under pkg.contrib/), plus up to 512
      bytes from the /dev/random device (it usually only returns a maximum
      number of bits of randomness currently contained in the device entropy
      pool) plus 512 bytes from the /dev/urandom device (which usually returns
      as many bytes as requested, but of low random-quality). Additionally
      before any new SSL connection is established the PRNG is again seed from
      the internal source plus up to 512 bytes from /dev/random and plus 512
      bytes from /dev/urandom. This should give an adequate seed for the PRNG
      used for generating the SSL protocol ingredients.

   *) Removed some unneccessary defines for `index' and `rindex'
      in etc/patch/config.h which caused problems under AIX.
   
   *) Changed a misleading sentence about RSAref in INSTALL

   *) Overtake the idea of Apache-SSL 1.30 to log SSL errors also directly
      after SSL_read/SSL_write. This way those error messages should no longer
      be missed.

      ____    _ 
     |___ \  / |
       __) | | |
      / __/ _| |
  __ |_____(_)_| _____________________________________________

  Changes with mod_ssl 2.1.8 (11-Jan-1999 to 21-Jan-1999)
   
   *) Added an additional variable REQUEST_SCHEME which can be used for in
      SSLRequire, RewriteCond, RewriteRule, etc.  to forward or redirect
      HTTP/HTTPS requests with the incoming URL scheme.

   *) Surrounded ap_hook_[un]register() calls with wrapper macros to
      implicitly cast the function pointers to void pointers, because strict
      ANSI C requires this.

   *) Added AP_HOOK_ALL support which can be used to call all registered
      callback-functions for a hooks, independent of any decline value.
      This will be used in the future by forthcoming features.

   *) Fixed a potential security hole: Both the SSLMutex and SSLSessionCache
      files are now created without read access for the group and others.

   *) Fixed a typo in the SSL logfile hints and in the terminal
      message displayed for the `make certificate' step.

   *) Under Extended API situations we now replace the module magic cookie
      "AP13" with "EAPI" to let us later distinguish between the EAPI-aware
      module structures (which contain additional pointers at the end) and
      standard module structures (which lack at least NULL's for the pointers
      at the end of the structure). This is important because standard
      ("AP13") modules would dump core when we dispatch over the additional
      hooks because NULL's are missing at the end of the module structure. 

      But we now to the following: We allow _both_ types of modules to be
      loaded by mod_so, but dispatch over the EAPI hooks only when the module
      magic cookie indicates "EAPI".  This way an Apache+EAPI server can load
      module DSOs built with a plain Apache. That's important to allow people
      for instance use mod_coldfusion (which is available only as a pre-built
      DSO!) or allow the Debian package maintainers to finally build their
      Apache package with EAPI without the need to upgrade all other module
      packages at the same time.

   *) The SSLMutex filename now is internally extended to contain the PID of
      the Apache parent process to make the file unique across different
      server instances. That's the same approach Apache already uses for the
      accept mutex lockfile.

   *) We now replace the MODULE_MAGIC_COOKIE ("AP13") with "EAPI" under -DEAPI
      to make sure that mod_so only loads modules which were really compiled
      with -DEAPI. Because else NULL's at the end of the module structure are
      missing, which always will leads to core dumps when the Apache core
      dispatches over it.

   *) Removed hints to the test suite in INSTALL.Win32 because under this
      platform there are more test suite problems before the tests can be
      really reasonable.

   *) Now mod_rewrite's %{XXXX} construct can also "magical