gecko-dev/security/nss/relnotes.txt

HCL Users,

HCL 1.5.7 has been released.  It fixes a very small list of bugs that
were found since HCL 1.5.6 was released, and contains no new features or 
public API changes.  The list of bugs fixed in HCL 1.5.7 is below.  
The release notes for HCL 1.5.6 are appended to these notes.  

ALL SERVERS should abandon HCL 1.5.6 and switch to HCL 1.5.7 ASAP.
The reasons for this strong recommendation should be self apparent after
reading the list of bugs fixed.

We recommend that all sources that include HCL headers be recompiled 
with the new HCL 1.5.7 headers.  This is only a precaution.


Security Library 1.57
Build Date: 19980902

****************************************************************
**
**  NOTE:  THIS RELEASE IS NOT BINARY COMPATIBLE WITH 1.55
**  	   AND ANY APPLICATION CODE WILL HAVE TO BE RECOMPILED
**
****************************************************************


****************************************************************
**
**  Directory organization of this release
**
****************************************************************

This release consists of the following:
- a JAR file, xpheader.jar, that contains all of the public header files.

- <platform> directories: where <platform> is of the form
  <os-name><os-version>[_<compiler>][_<implementation strategy>]_<DBG/OPT>.OBJ
  For example,
      IRIX6.2_DBG.OBJ (debug build)
      SunOS5.5.1_OPT.OBJ (optimized build)
      SunOS5.5.1_gcc_DBG.OBJ (built using the non-native compiler gcc)
      OSF1V4.0_PTH_DBG.OBJ (PTH means the implementation uses pthreads.)
      AIX4.1_PTH_USER_DBG.OBJ (PTH_USER means the implementation is
          a combination of user-level threads and pthreads.)

  Under each <platform> directory, is the file, mdbinary.jar.  This is a
  JAR file containing the compiled libraries.


************************************************************
**
**  Platforms supported
**
************************************************************

The following platforms are supported:
- Solaris on sparc: 2.5.1, 2.6 (built with cc) 
- IRIX: 6.2, 6.3 (built with cc)
- HP-UX: B.10.10, B10.20, B11.00 (built with cc)
- OSF1: V4.0D (built with cc)
- AIX: 4.2 (built with compiler xlC_r).
- Linux: 2.1.108
- WINNT: 4.0 (Visual C++ 4.2 built with and without debug runtime)


************************************************************
**
**  How to build the libraries yourself
**
************************************************************
This release of HCL depends on NSPR version 19980529A and 
DBM version DBM_1_53.

To build the libraries yourself, execute the following instructions.

On UNIX machines:
	cvs co -r HCL_157 ns/security
	cvs co -r HCL_157 ns/coreconf
	cd ns/coreconf
	source ./.cshrc
	gmake [BUILD_OPT=1]
	cd ..
	cd security
	gmake [BUILD_OPT=1] import
	gmake [BUILD_OPT=1]

On Windows NT machines:
	cvs co -r HCL_157 ns/security
	cvs co -r HCL_157 ns/coreconf
	cd ns/security
	gmake [BUILD_OPT=1] import
	gmake [BUILD_OPT=1]

For IRIX builds using -n32 flag with pthreads:
	cvs co -r HCL_157 ns/security
	cvs co -r HCL_157 ns/coreconf
	cd ns/coreconf
	source ./.cshrc
	gmake USE_N32=1 USE_PTHREADS=1 [BUILD_OPT=1]
	cd ..
	cd security
	gmake USE_N32=1 USE_PTHREADS=1 [BUILD_OPT=1] import
	gmake USE_N32=1 USE_PTHREADS=1 [BUILD_OPT=1]

	
************************************************************
**
**  Web site, mailing lists, questions, bug reports
**
************************************************************

You can find information about the Security Libraries at the Hardcore Web
site: http://warp/projects/hardcore/

If you have any questions regarding SSL or the HCL libraries, please refer to the 
following documents:  
	http://twain.mcom.com/developer/security/nss/ssl/index.htm
	http://twain.mcom.com/developer/security/nss/index.htm

There is a mailing list for HCL issues:
  - hcl: the developers of HCL.

Please use BugSplat on scopus (http://scopus/bugsplat) to report
bugs.  Choose product "Security Library", version "1.5".


Here's how/where to get HCL 1.5.7:

bits are available at
/m/dist/security/19980902  a.k.a.  /m/dist/security/HCL_1_57

\\helium\dist\security\19980902  or \\helium\dist\security\HCL_1_57


Here is the list of bugs fixed in HCL 1.5.7:
a) Thread safety-related crash in cert lib.

b) Thread safety-related problems in NSPR's PL_Arena code.  
   Worked around by surrounding all HCL's PL_Arena calls with a lock/unlock.
   Applications that make their own calls to NSPR's PL_Arena functions or 
   that use other non-HCL libraries that use PL_Arenas may continue to have 
   thread-safety issues with PL_Arenas.

c) Fixed a regression in PKCS#11 in HCL 1.5.6 that caused a crash the 
   first time a server received a bleichenbacker attack ("million question")
   message.

See the HCL 1.5.6 release notes below for the list of known bugs in 1.5.7.


Here is a list of the bugs fixed in HCL 1.5.6:

312467 SSL3 uses global pointers for step-down keys, leaks keys  
314392 CERT_DestroyCertificate locking code causes nested locking  
314571 Memory leak in SSL  
314574 HCL Leaks in PKCS #11.  
314576 Memory leak in pseudo-prime test in libcrypto  
314585 SSL's PR_AcceptRead returns non-aligned PRNetAddr  
314592 pkcs5 leaks two memory blocks for each RSA private key op  
314596 random number generator causes Unitialized Memory Reads  

------------------------------------------------------------------------
                   HCL 1.5.6 Readme (release notes)
------------------------------------------------------------------------

This file summarizes enhancements, fixed and known bugs in HCL 1.5.6.

For detailed instructions on setting up your environment to run the
sample code in the samples directory, see Chapter 2, "Getting Started
with SSL" (doc/ssl/gtstd.htm) of the SSL Reference (doc/ssl/index.htm).


ENHANCEMENTS SINCE NSS 1.5.4

1. SSL returns much more detailed error messages; for details, see 
doc/ssl/sslerr.htm

SSL BUGS FIXED SINCE HCL 1.5.4

1. The "million question" bug in SSL has been fixed.

2.  A potential problem (on Unix only) with SSL_InitSessionIDCache has
been fixed.  The application chooses the directory into which the SSL
library places the server session cache.  If the application doesn't
specify a directory explicitly, the code defaults to using the system
default "temporary" directory, which is generally world-writable.  The
problem that was fixed occured only when the application chose to put
the session cache files into a directory writable by untrusted users.
If the application put the cache files in a directory that has
appropriate limits on access, there was no problem.  But if the
application put the cache files into a directory that was world
writable, it was possible for a rogue program to try to substitute a
file it already had open for the server's cache file, and it would
succeed some of the time.  When it succeeded, it had access to the
content of the session ID cache, which enabled it to do various bad
things, such as masquerade as one of the remote clients whose session
was in the cache.

The above problem with the Unix version of SSL_InitSessionIDCachehas
been fixed, and rogue programs cannot succeed in substituting their own
files for the server's files any more.

3.  Client no longer rejects SSL ServerKeyExchange when server's
certificate key size is 512 bits.

4.  Server no longer crashes in SSL after required client authentication
fails.

5.  A problem that was causing crashes when multiple threads
simultaneously requested client authentication on their respective
server sockets has been fixed.

6.  The following functions now work with SSL sockets:

   PR_Write
   PR_TransmitFile
   PR_AcceptRead

7. SSL now accepts client hellos that are too long.
 
8.  A problem that produced bad results when multiple threads
simultaneously used the random number generator has been fixed.



KNOWN BUGS IN HCL 1.5.6:

1.  A crash may occur when multiple processes attempt to share a server
session ID cache.  Because of this bug, an application that handshakes
as a server is limited to conducting all SSL calls in a single process.

2. Removing a token does not invalidate the client-side session cache.

3.  While a handshake is in progress on an SSL socket, it is not safe
for two threads to attempt simultaneous read and write calls (PR_Recv
and PR_Send) on that socket.  Workaround: ensure that only one thread
uses an SSL socket at a time.

We expect the above 3 bugs will be fixed in a forthcoming release.

SSL v2 issues in HCL 1.5.x:

1.  SSL_RedoHandshake only works on SSL3 connections, not SSL2.  The
SSL2 protocol does not permit additional handshakes on the connection
after the first one is done.  Ergo, if a client certificate is to be
requested in an SSL2 connection, it must be requested on the initial
handshake.

2.  HCL's SSL2 ignores the setting of the SSL_REQUIRE_CERTIFICATE
enable.  When SSL_REQUEST_CERTIFICATE is enabled, SSL2 behaves as if
SSL_REQUIRE_CERTIFICATE is also enabled, regardless of the actual
setting of the SSL_REQUIRE_CERTIFICATE enable.

3.  HCL's SSL2 server code doesn't call the bad cert handler callback
when the authCert callback returns an error.  The ssl2 client code DOES
use the badcerthandler callback, but the ssl2 server code does not.
This means that if the server's authCert callback returns SECFailure,
rejecting the client cert received on an SSL2 connection, the
badCerthandler cannot override it.

4.  HCL's SSL2 server code never caches the client cert.  Consequently,
if an SSL2 server is configured to request the client cert, it must ask
the client for the client cert on every connection, not just on the
first connection in the "session".   The SSL2 client must provide the
cert in every SSL2 connection that requests it.  If the user has set the
"ask me every time" option for his certs, he will get prompted a LOT.

Item 1 above is not a bug.  That's the way ssl2 is defined.  Items 2-4
are limitations of our implementation.  TomW says client auth in ssl2
was never officially supported (although it is mostly implemented).

Recommended workaround for SSL2 issues:

a) Don't expect client auth to work for SSL2 users.
b) Don't request client auth in the initial handshake.  Request it in a
subsequent handshake (e.g. set SSL_REQUEST_CERTIFICATE and call 
SSL_RedoHandshake() on SSL3 connections.  This will completely avoid 
client auth problems with SSL2.  

For some time now, we've been suggesting that servers request client
auth on a second handshake, not the first handshake in the connection.
If they do that, then they will never get client certs from ssl2
clients.  That is a good thing.