From Fedora Project Wiki
 
(11 intermediate revisions by the same user not shown)
Line 3: Line 3:


== Summary ==
== 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.
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 should also be packaged separately as nss-utils.


== Owner ==
== Owner ==
Line 15: Line 15:


== Detailed Description ==
== 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.  
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 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.
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 ==
== Benefit to Fedora ==
Line 25: Line 25:
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.  
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
The nss shared libraries which are currently distributed as:
 
   nss: libnss3.so, libnssutil3.so, libnssdbm3.so, libssl3.so,  
   nss: libnss3.so, libnssutil3.so, libnssdbm3.so, libssl3.so,  
       libsmime3.so, libsoftokn3.so, libsoftokn3.chk, libnssckbi.so, libnsspem.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-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
   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)
   nss-softokn: libsoftokn3.so, libsoftokn3.chk
   util: ibnssutil3.so
 
   nss-softokn-freebl: libfreebl3.so, libfreebl3.chk (subpackage of softokn)
    
  nss-util: libnssutil3.so
 
Currently nss has a subpackage nss-devel with the headers and development libraries that will get distributed among the new packages. nss-softoken aND nss-util own development subpacakegs will install the portion of the headers of relevamce to them. Each becomes the "owner" of its share of the headers. They will be installed in the same location as before the split so as to make this change transparent to existing client packages.


== How To Test ==
== How To Test ==
Line 44: Line 52:
Examples of these are glibc, mod_nss, nss_compat_nss, crypto-utils, openswan, xulrunner, evolution, and Pidgin's libpurple.
Examples of these are glibc, mod_nss, nss_compat_nss, crypto-utils, openswan, xulrunner, evolution, and Pidgin's libpurple.


== Building NSS ==
== Building NSS : pre-flight and test ==
 
For a description on how to perform and test major nss updates see
You will need to build the three packages is this order:
https://fedoraproject.org/wiki/Updating_NSS#Updating_NSS
nss-util, nss-softokn, and nss.
The above applies to Fedora and RHEL-6 and above.
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 on the branch for the next fedora release after the branching which occurs with alpha. In these cases one must wait for one package to be tagged into the build root before one can build the subsequent one. Often you will have some urgency. The procedures is to open a ticket asking that the package you built be added to the buildroot and wait until so to proceed to the next one.
 
NOTE 1: Don't try shortcuts. 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 but will likely cause breakage later on when you try to install and some package that depends on nss or any of its siblings will fail to install or to build. All three packages have devel sub-packages. The version used for BuildRequire must the one used for Requires.
 
NOTE 2: One must coordinate with release engineering to progressively add packages to the buildroot. It takes waiting. Furthermore, before sending request to release engineering one must get some assurance that all builds will succeed and and will not cause conflicts and avoid repeated requests. Preflight and testing are necessary.
 
Submitting scratch builds is not sufficient because they will not get installed into the buildroot and we are building several packages which depend on previous ones.
 
One approach could be to 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.
 
A better 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
 
Herer's how we do it for nss.
 
'''Building nss, nss-sotokn and nss-util using mock.'''
 
(If you haven't done so add ourself to the mock group usermod -a -G mock myusername)
 
Use Mock outside your git sandbox to build nss-util
 
Make nss-util using mock and also create the srpms for nss-softokn and nss
which we will build inside the sandbox.
 
<pre>
cd {were-the git-checkouts-are}/nss-util; fedpkg srpm
mock -r fedora-rawhide-x86_64 --rebuild nss-util-{v}-{r}.fc15.src.rpm
cd ../nss-softokn; fedpkg srpm
cd ../nss; fedpkg srpm
</pre>
 
Use Mock inside your git sandbox to build nss-softokn and nss
First, initialize the mock repository:
 
<pre>
mock -r fedora-rawhide-x86_64 --init
</pre>
 
Install the packages needed to build nss-softokn and nss
(named in BuildRequires) from the yum repositories and local RPMs.
 
<pre>
mock -r fedora-rawhide-x86_64 --install \
sqlite-devel zlib-devel pkgconfig gawk psmisc perl nss-devel
mock -r fedora-rawhide-x86_64 --install nss-util-{v}-{r}.fc15.rpm \
nss-util-devel-{v}-{r}.fc15.rpm
</pre>
 
Copy in the nss-softokn source RPM into /tmp
(we'll copy in and do a build inside the shell, to work around the checks that
detect that the packages aren't in the repository):
 
<pre>
mock -r fedora-rawhide-x86_64 --copyin /PATH/TO/NSS_SOFTOKN_SRPM_NAME /tmp
mock -r fedora-rawhide-x86_64 --copyin /PATH/TO/NSS_SRPM_NAME /tmp
</pre>
 
Shell into the mock environment and perform the builds:
 
<pre>
mock -r fedora-rawhide-x86_64 --shell
cd
rpmbuild --rebuild /tmp/nss-softokn-{v}-{r}.fc15.src.rpm
</pre>
 
Prepare to Build nss
First add yourself as a user, password doesn't matter, to run the build (and test) as yourself not root.
If the system doesn't find you it will run as root and this will cause two tests
to fail.
 
<pre>
userdd yourname
cd /builddir/build/rpms
rpm -Uhv nss-softokn-{v}-{r}.fc15.rpm nss-softokn-freebl-{v}-{r}.fc15.rpm  nss-softokn-devel-{v}-{r}.fc15.rpm    nss-softokn-freebl-devel-{v}-{r}.fc15.rpm
</pre>
QESTION: Do we need this step?
 
Now we are ready to build nss
 
<pre>
cd
su yourname
rpmbuild --rebuild /tmp/nss-{v}-{r}.fc15.src.rpm
</pre>
 
The nss build will take some time because we run all tests
Once it suceeds you can install it and try a client application
The results are in /home/yourname/rpmbuild/RPMS/x86_64
 
<pre>
exit (bring you back to being root)
cd /home/yourname/rpmbuild/RPMS/x86_64
rpm -Uhv {list-of-rpms}
su yourname
rpm -q curl will confirm that it is installed, use it to access a site
$ curl https://fedoraproject.org/wiki/Bodhi_Guide
</pre>
 
Question: This is just a minimal test, can we do some others?
 
Now we are confident that the real builds will work.
We haven't done much testing. Can we build another packkage that is a client of nss?
crypto-utils is a simple client that we could build in our environment.


== User Experience ==
== User Experience ==

Latest revision as of 15:57, 3 September 2014

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 should also be packaged separately as nss-utils.

Owner

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

 nss-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

 nss-softokn: libsoftokn3.so, libsoftokn3.chk

 nss-softokn-freebl: libfreebl3.so, libfreebl3.chk (subpackage of softokn)
 
 nss-util: libnssutil3.so

Currently nss has a subpackage nss-devel with the headers and development libraries that will get distributed among the new packages. nss-softoken aND nss-util own development subpacakegs will install the portion of the headers of relevamce to them. Each becomes the "owner" of its share of the headers. They will be installed in the same location as before the split so as to make this change transparent to existing client packages.

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 The above applies to Fedora and RHEL-6 and above.

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


Retrieved from "https://fedoraproject.org/w/index.php?title=Features/SplitSoftoknFromNSS&oldid=385858"