Features/SplitSoftoknFromNSS

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
(Scope)
(30 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section.  They are invisible when viewing this page.  To read it, choose the "edit" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.'''}}
 
 
<!-- All fields on this form are required to be accepted by FESCo.
 
We also request that you maintain the same order of sections so that all of the feature pages are uniform.  -->
 
 
<!-- The actual name of your feature page should look something like: Features/YourFeatureName.  This keeps all features in the same namespace -->
 
 
 
= Feature Name =
 
= Feature Name =
Split Softokn off from NSS
+
Split Softoken off from NSS
  
 
== Summary ==
 
== Summary ==
The softokn cryptographic module of NSS should be split off as 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 utils should also be packaged separately as nss-utils.
  
 
== Owner ==
 
== Owner ==
 
* Name: [[User:FASAcountName| emaldonado]]
 
* Name: [[User:FASAcountName| emaldonado]]
 
 
* email: emaldona@redhat.com
 
* email: emaldona@redhat.com
  
 
== Current status ==
 
== Current status ==
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]
+
* Targeted release: Fedora 12
* Last updated: (DATE)
+
* Last updated: 2009-0726
* Percentage of completion: 75%
+
* Percentage of completion: 100%
 
+
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
+
  
 
== Detailed Description ==
 
== Detailed Description ==
The softokn cryptographic module of NSS should be split off as the nss-softkn pacakage. A set of utilities called by both softokn 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 35: 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
 
  
would be distributed among the packages as
+
  nss-softokn-freebl: libfreebl3.so, libfreebl3.chk (subpackage of nss)
   nss: libnss3.so, libnssutil3.so, libnssdbm3.so, libssl3.so, libsmime3.so, libnssckbi.so, libnsspem.so
+
 
   softokn: libsoftokn3.so, libsoftokn3.chk
+
would be distributed among the packages as:
   softokn-freebl: libfreebl3.so, libfreebl3.chk
+
 
   util: ibnssutil3.so
+
   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 ==
 
== How To Test ==
 
Separately package nss, nss-softokn, and nss-util all having the same version numbers.
 
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 gor FIPS validated.
+
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.
 
There should not be conflicts at installation time in either of the above cases.
Components that depend on NSS should install withourt conflicts
+
Components that depend on NSS should install without conflicts
 
There should be no regressions for components that depend on NSS.
 
There should be no regressions for components that depend on NSS.
Examples of these are glibc, mod_nss, nss_compat_nss, crypto-utils, openswan, 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 : 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 ==
 
== User Experience ==
Line 58: Line 60:
  
 
== Dependencies ==
 
== Dependencies ==
glibc, pmod_nss, nss_compat_nss, crypto-utils, openswan, and libpurple are some packages that depend on NSS. NSSS has no significant dependencies except for NSPR and this would have no effect on this relationship.
+
Upstream NSS 3.12.4 where some code reorganization was made to facilitate this work.
 
+
  
 
== Contingency Plan ==
 
== Contingency Plan ==
Line 67: Line 68:
  
 
== Documentation ==
 
== Documentation ==
* A proof of concept implementation of this proposal can be obtained by executing
+
* This proposal has been implemented in Rawhide
git clone git://fedorapeople.org/~emaldonado/splitnss.git
+
  
 
== Release Notes ==
 
== Release Notes ==
* The Fedora Release Notes should describe the new packaging.
+
*The softokn cryptographic module of NSS has been split off as the nss-softokn package
  
 
== Comments and Discussion ==
 
== Comments and Discussion ==
 
* See [[Talk:Features/SplitSoftoknFromNSS]]  
 
* See [[Talk:Features/SplitSoftoknFromNSS]]  
 
  
 
[[Category:FeaturePageIncomplete]]
 
[[Category:FeaturePageIncomplete]]
Line 83: Line 82:
 
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
 
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
 +
 +
{{Anchor|Recommendations}}

Revision as of 16:47, 20 January 2012

Contents

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

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

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