+++ This bug was initially created as a clone of Bug #508479 +++ It is extremely difficult to upgrade NSS while at the same time keeping the FIPS validated cryptographic module. NSS is FIPS 140-2 validated but it is actually the nss softoken pkcs #11 module that is granted the FIPS 140 validation as a cryptographic module. Only the softoken and frebl libraries are inside the "cryptographic boundary" and get validated, the rest of NSS lies outside the boundary. The current monolithic packaging of NSS makes it extremely hard to support users who rely on the FIPS validation so they can upgrade NSS and take advantage of crucial fixes while at the same time continuing to use the current FIPS validated cryptographic module. RHEL needs to keep updating NSS while at the same time ship NSS with the last validated softoken. Packaging softoken separately from the rest of nss will solve these problems. The nss utils library is a set of non-cryptographic utilities that softoken and the rest of nss depend on should also be packaged separately. In the upcoming NSS 3.12.4 from upstream, some re-factoring of code and include files has been done to enable such re-packaging possible for us downstream in Fedora and RHEL. Version-Release number of selected component (if applicable): How reproducible: N/A Steps to Reproduce: N/A Actual results: Expected results: Additional info:
Created attachment 354493 [details] Changes to make softokn and utils subpackages This is a first cut at splitting off softkn and util by making them subpackages of nss. The handling of separate version and release numbers for the subpackages, of Requires, Conflicts (and possibly Obsoletes) stanzas needs careful review and testing.
An early stab at splitting off softkn and util as packages on teheir own, separte yet related, can be obtain examined via git clone git://fedorapeople.org/~emaldonado/splitnss.git
The split was preformed on Fedora 12 and RHEL 6.
Also the split is done on RHEL 6 but not on RHEL 5 as it is a major repackaging that introduces new rpms and threfore not appropriate for the RHEL 5 series of upgrades.