Feature Name
Split Softoken off from NSS
Summary
The softoken cryptographic module of NSS should be split off as the nss-softokn package. The utilities library which is a common library required by softokn and the rest of nss utils should also be packaged separately as nss-utils.
Owner
- Name: emaldonado
- email: emaldona@redhat.com
Current status
- Targeted release: Fedora 12
- Last updated: 2009-0726
- Percentage of completion: 100%
Detailed Description
The softoken cryptographic module of NSS needs to be packages on its own as the nss-softkn pacakage. as a consequence a set of utilities called by both the new softoken and the rest of NSS would also need to be packaged as its own package.
NSS is FIPS 140 validated but what is really submitted for FIPS 140 validation is the cryptographic module sunset, that is, that is the softken PKCS #module. This split will enable users as well as package maintainers to upgrade to the current version of NSS while preserving the last FIPS validated version of the cryptographic module if they so require. Fedora based distributions such as RHEL would greatly benefit from this feature in terms of easier long term maintenance.
Benefit to Fedora
It will make Fedora a convenient Linux distribution to use when trying to be FIPS compliant.
Scope
This will not affect developers as it is a packaging change only and no changes to the NSS API are required nor changes to their build systems. The same libraries are shipped as before. They just get distributed among three packages.
The nss shared libraries which are currently distributed as
nss: libnss3.so, libnssutil3.so, libnssdbm3.so, libssl3.so,
libsmime3.so, libsoftokn3.so, libsoftokn3.chk, libnssckbi.so, libnsspem.so
softokn-freebl: libfreebl3.so, libfreebl3.chk (subpackage of nss)
would be distributed among the packages as
nss: libnss3.so, libnssdbm3.so, libssl3.so, libsmime3.so, libnssckbi.so, libnsspem.so softokn: libsoftokn3.so, libsoftokn3.chk softokn-freebl: libfreebl3.so, libfreebl3.chk (subpackage of softokn) util: ibnssutil3.so
How To Test
Separately package nss, nss-softokn, and nss-util all having the same version numbers. Separately package nss, and nss-util as the latest release while keeping nss-softokn at an earlier release such as the current release which was FIPS validated. There should not be conflicts at installation time in either of the above cases. Components that depend on NSS should install without conflicts There should be no regressions for components that depend on NSS. Examples of these are glibc, mod_nss, nss_compat_nss, crypto-utils, openswan, xulrunner, evolution, and Pidgin's libpurple.
Building NSS : pre-flight and test
For a description on how to perform and test major nss updates see https://fedoraproject.org/wiki/Updating_NSS#Updating_NSS
User Experience
Neither developers nor end users should notice any difference with the exception seeing more packages being installed if they look closely at their yum installs or upgrades.
Dependencies
Upstream NSS 3.12.4 where some code reorganization was made to facilitate this work.
Contingency Plan
There are two contingency plans in case this split cannot be accomplished in time. 1) Make softokn and util sub-packages of nss instead of stand-alone packages. 2) Revert to using the current monolithic approach.
Documentation
- This proposal has been implemented in Rawhide
Release Notes
- The softokn cryptographic module of NSS has been split off as the nss-softokn package
Comments and Discussion