зеркало из https://github.com/mozilla/gecko-dev.git
Bugzilla Bug 279621: removed relnotes.txt, which contains HCL 1.7.5 release
notes.
This commit is contained in:
wtchang%redhat.com
Родитель
e8a0db789d
Коммит
2aadb23379
|
|
@ -1,284 +0,0 @@
|
|||
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.
|
||||
|
||||
Загрузка…
Ссылка в новой задаче