Features/SplitSoftoknFromNSS

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 would be the nss-softkn pacakage. A set of utilities called by both 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 validation is the cryptographic module, that is, softkn. This split is to enable users and packagers 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, but not limited to, RHEL would greatly benefit from this feature in terms of 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.

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

• See Talk:Features/SplitSoftoknFromNSS

Recommendations for the Package Maintainer

You will need to build the three packages is this order: nss-util, nss-softokn, and nss. In Rawhide the buildroot is updated frequently and we can also count on chained builds. This is not the case on the stable branches or the branch for the next fedora release after the branch which occurs with alpha. In these cases one must wait for the one package had been tagged into the build root before one can build the subsequent one. Often you will have some urgency. The procedures is open a ticket asking that the package you build be added to the builtroot and wait until so to proceed to the next step.

NOTE: Do not introduce a BuildRequire that is lower than the Require just so to be able to build the next package right away. It may build okay but will likely cause breakage later on when you try to install or some package that depends on nss will fail to build. All three packages have devel sub-packages. The BuildRequire must match the Requires in terms of version.

NOTE: One must coordinate with release engineering to progressively add packages to the buildroot. It takes waiting. Furthermore, one must get some assurance that all builds will succeed and and will not cause conflicts and avoid repeated request to release engineering. Testing is necessary.

Just submitting scratch builds is not sufficient because they will not get installed into the buildroot.

One could use multiple system builds and installs in various VM's. Once you have downloaded the packages, a 'yum --nogpgcheck localupdate packages-we-have-so-far' is one way to accomplish this. All dependencies must be satisfied and no conflicts shuould result.

Another way is to do mockbuilds and add the packages to our local buildroot as we go along. See http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#Building_packages_that_depend_on_packages_not_in_a_repository