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:
In a recent conversation with some folks it was brought up that the split of softokn and util could be accomplished in two ways: 1: Split off nss-softkn and nss-utils their own packages. Pros: gives us the ability to ship nss-softokn (and nss-utils) independently of the rest of nss with their very own versions. RHEL would greatly benefit in being able to follow the Fedora spec files rather closely. Cons: Introducing two new packages does require more review to get it in F-12 and may require more testing. 2: Make nss-softkn and nss-utils subpackages if nss in the nss.spec file similarly to what was done for nss-softkn-freebl. Pros: Requires less review, may be simpler to implement, may require less testing thus more likely to have it done on time for F-12. Cons: Keeping separate versions of subpackages is a bit trickier and may not simplify maintenance in RHEL as much as we wish for. For the Fedora 12 Feature Page please see https://fedoraproject.org/wiki/Features/SplitSoftoknFromNSS#Feature_Name An early proof-of-concept implementation can be obtained via git clone git://fedorapeople.org/~emaldonado/splitnss.git
FESCo sayd: "This was declined as a feature, due to the fact it seems to be mostly package reorganization, with no visible changes." To this end I have created Bug 515032 and Bug 515034 to introduce nss-util and nss-softokn as packages.
Created attachment 356056 [details] nss.spec file without nss-softokn and nss-utils This is not for a formal review as it requires the split of nss-softkn and nss-util into their own packages which is pending review. I just want to show some progress and elicit comments and questions.
(In reply to comment #3) My own comments: 1. Remove the %files softokn-freebl line the next two since it softokn-freebl is now a subpackge of nss-softokn. 2. nss-nolocalsql.patch patches files inside softokn so it should be moved to nss-softokn.spec and applied fron nss-softokn.spec. Luckily this patch is limited to softokn files plus one Makefile above it which is included when we create the softokn tar out of the big one. This brings up a previously unanticipated problem. There may be patches that include files across softkn, util, and the rest of nss. It looks like we would have to split them up into multiple patches ourselves or maybe ask the originator to do so.
Created attachment 356324 [details] this patch addresses review comments nss-softokn-freebl and two softokn-only patches moved out to the nss-softokn.spec.
Created attachment 356325 [details] the full nss.spec file after the patch is applied
re comment #4. unlikely that we could have any more combined patches. NSS upstream will have a pretty strong 'lock' on softoken, so any patches would already have to be split in the upstream version (with the softoken parts checked into a softoken branch). bob
Created attachment 357081 [details] Changes to spec file required by split of softokn and util nss, nss-softokn, and ns-util "share" onwership of /usr/include/nss3, so to speak, instead of nss-util being the owner. I still run into install conflicts when installing or upgrading in a system with an older version of nss. Shared ownership among the three packages is a problem I haven't solved and need some advise on.
Created attachment 357082 [details] The spec file after 357081 is applied
Copies of all three .spec files (nss, nss-softkn and nss-util) can be found at http://fedorapeople.org/~emaldonado/specfiles/
Created attachment 357838 [details] Changes to spec file required by split of softokn and util
Created attachment 357839 [details] spec with the changes applied
Created attachment 357847 [details] changes to nss.spec and nss.pc.in required by the patch
Now that I got r+'s on the other two bugs one next logical step would be to review the attachments for this one. Bob, could you review this one as well?
Requesting Bob Relyea's review of nss.spec, nss.pc.in and nss-conf for Rawhide.
Reviewing what is on top of the tree Delete the following Requires: sqlite nss-softoken-freebl%{isa} nss-util (optionally) delete the following BuildRequires: nss-util nss-softokn sqlite-devel (should be pulled in by nss-softokn if necessary) ># we must compile with the entire source tree because nss needs ># private exports from util. The install section will ensure not ># to override nss-util and nss-softoken headers already installed. this needs to be fixed... we should use the real headers and fixe the private exports issues. > #remove the nss-util-devel headers This should be necessary once the above is fixed.
We chose the "softokn" name, without the "e", to make the Windows DLL name "softokn3.dll" fit the DOS 8.3 naming constraint. For the Linux package name, we should not omit the "e". Is it too late to rename this package nss-softoken?
(In reply to comment #17) This package was named nss-softokn for consistency with the previously released nss-softokn-freebl which now becomes a sub-package of this one. I wish we had placed the "e" then. I'm afraid it is too late to change the names.
I guess libfreebl3.so has to be its own package because the nss-softokn package would pull in the nspr and nss-util packages? Can we shorten the nss-softokn-freebl package name? The package name doesn't need to mention the softoken. I think nss-hash, nss-lowhash, nss-low, or nss-freebl would all be a good name. I hope we can fix these package names before they are locked into a RHEL release.
Freebl has it's own package because it needs to be installed 'solo' for glibcrypt which uses it. Freebl itself is part of the softoken package (that is the source code updates are softoken/freebl combined). It's a subpackage of nss-softokn (not nss). The name was chosen several months ago when we put the code in for glibcrypt. At the time it was part of the nss package, but we knew it was going to be part of the nss-softokn package, so we named it the softokn-freebl package of nss. This allowed us to smoothly handle the transition to multi-nss. This is why the name of the nss-softokn package was fixed. To summarize: 1) nss-softokn-freebl must have a name with nss-softokn at the front no matter what. 2) The full name had been locked in several months ago (Fedora 8 or 9) and we are unlikely to change unless there is something really wrong with the name. RE: softokn verses softoken. Since the name of the base library is softokn, it makes sense that the package name is softokn as well. Having 2 names could be confusing.
> RE: softokn verses softoken. Since the name of the base library is softokn, it > makes sense that the package name is softokn as well. Having 2 names could be > confusing. I concur, consistency is important.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.