8.152. nss

Bug Fixes

BZ#606022

The manual pages for the NSS security utilities were missing. This update adds the missing manual pages.

BZ#895339

Previously, the curl utility failed to communicate with active FTP over Secure Sockets Layer (SSL) where both control and data connections were encrypted and authenticated by a client certificate with a password-protected private key. This was caused by the Privacy Enhanced Mail (PEM) module that pretended token removal whenever a key was being loaded from a file. Consequently, when the private key was loaded to authenticate the data connection, it caused the already authenticated control connection to fail with the following error code:

SSL_ERROR_TOKEN_INSERTION_REMOVAL.

The underlying source code in the NSS PEM module has been modified, and loading a single key multiple times no longer causes an SSL connection to fail.

BZ#993441, BZ#1004105

With this update, the nss-softokn module has been submitted for a FIPS-140 revalidation.

BZ#1031238

The code for removing token certificates from the cache caused a deadlock. Under certain conditions, when a server was processing multiple outgoing replication or windows sync agreements using TLS/SSL and processing incoming client requests that use TLS/SSL and Simple Paged Results, the server became unresponsive to new incoming client requests. With this update, the underlying source code has been modified to fix this bug and clients of NSS no longer become unresponsive in the described scenario.

BZ#1044666

The NSS libraries did not check whether the NSS_SDB_USE_CACHE environment variable was set to “yes” before calling the sdb_measureAccess() function. Consequently, when using the cURL or libcurl libraries that depend on NSS to make a HTTPS requests, there were many “access” system calls to paths, directories, and files that did not exist. This behavior led to excessive size of the directory entry cache. This update modifies NSS to avoid calling sdb_measureAccess() when NSS_SDB_USE_CACHE is set to “yes”, thus limiting the system calls to the non-existent paths. As a result, cURL HTTPS requests no longer cause the cache to be too large.

BZ#1053437

Previously, an incorrect CHECK_FORK() call in the nss-softokn module prevented the Admin Server component of Red Hat Directory Server from recovering after an improper shutdown. As a consequence, the Red Hat Directory Server parent process was unable to shut down NSS. Therefore, when Red Hat Directory Server was configured on an SSL port, the Admin Server component terminated unexpectedly with a segmentation fault. With this patch, the problematic CHECK_FORK() calls have been removed and users can now start Red Hat Directory Server and use SSL-encrypted traffic as expected.

BZ#1057224, BZ#1057226

The section in the spec file that is used to set and export the NSS_ENABLE_ECC and NSS_ECC_MORE_THAN_SUITE_B build time environment variables was missing. Consequently, NSS was prevented from allowing external pkcs #11 cryptographic modules to support Elliptic Curve Cryptography (ECC) algorithms beyond those specified in suite B, thus preventing support for pluggable ECC. The mentioned spec file has been fixed and pluggable ECC are now supported as expected.

BZ#1059176

Previously, the NSS libraries allowed users to disable the internal cryptographic module. When users set up an external cryptographic module, such as opencryptoki, as the preferred module and disabled the internal cryptographic module, NSS could terminate unexpectedly with a segmentation fault. NSS has been modified to prevent users from disabling the internal module and therefore no longer fails in the described scenario.

BZ#1090681

Due to a race condition in functions that manage user-defined slots, the PK11_DoesMechanism() call failed on the Red Hat Directory Server. The code that manages the user-defined slots now checks if the slot is present and skips any reinitialization, cached present values, and locking. If the module is not thread-safe, as is the case with the Privacy Enhanced Mail (PEM) module, the slot sessionLock is the same as the module reference lock and there is no need to use sessionLock. As a result, PK11_DoesMechanism() no longer crashes.