NSS SHARED UTIL

Making util it's own shared library

For a long time, it's been highly desired that util become it's own shared library, since it statically links with nss3, softokn3, and freebl. This page is to talk about different approaches for implementing this, and the various issues with each approach.

One issue we have is nss3 is exporting symbols directly from util. This creates a problem when util is no longer part of nss3. (I believe this issue is the issue that has kept util from becoming it's own library to date).

Approach 1, straight forward refactoring.

In this approach we simply create a new shared library (call it libnssutil.so for now), and remove the symbols for nss3. Each application would link directly with this library. Existing apps would get their symbols fulfilled with the new nssutil because nss3 would pull it in as a dependency. For testing purposes, I was able to implement this approach in just a couple of hours (including builds and tests). The problem with this approach is this shared library suddenly becomes visible at the application level. Where as before, when we added new shared libraries, application's build systems did not need to change, only their packages, this approach requires link line changes with applications that reference functions in libnssutil.so (which is likely just about all of them). Binary compatibility should be preserved since existing applications load nss3, which will pull in nssutil as a dependency, so already compiled applications will continue to work.

Pros:

1. This is the simplest and most natural way of using the library. It's they way we would have designed it if nssutil was required for this from the beginning.
2. We believe we can maintain binary compatibility.
3. Work involves:
   • some make file changes,
   • a thorough auditting to make sure nssutil.def has exactly the right exported symbols,
   • remove the appropriate symbols from nss3.def,
   • and add the new NSS_Get_() functions for templates nss3, softoken, and freebl need that weren't already exported.

Cons

1. We need to test the compatibility claims on other platforms. Do we have any platform that will scream if a symbol formerly available in nss3 is no longer available there (assuming it's still available in the shared library chain).
2. There is a build time breakage we will need to communicate. (It's a simple fix, but it is a change.).

Approach 2 nss3 redirect to nssutil

In this approach we rename the functions in nssutil and continue to redirect them from nss3. This has 2 problems. First we need to rename the usage of those functions in softoken and freebl, since they call util directly. Second we export a number of data symbols. On some platforms, data was not exportable, so forwarding the NSS_Get_() functions is fine. On platforms where we did export the data, however, we will need to include copies of those templates in nss3 as well as util.

Pros

1. No build time changes for applications.
2. More confidence in maintaining binary compatibilty.

Cons

1. Data duplication in nss3 (data templates).
2. Potentially ugly exports for nssutil.
3. All the changes required fro Approach 1 plus:
   • Name changes to the calls in freebl, softoken, and util (potentially with a header file.
   • Set of stub functions in nss3 to redirect calls into nss3 into nssutil (roughly 180 functions).
   • copy exported data templates from nssutil to nss3 (roughly 20 templates)

Recommendations

I feel approach 1 would be the preferred approach. The decision not to go with approach 1 would hinge on the following:

1. If my evaluation to the binary compatibility does not hold, approach 1 is a non-starter.
2. If the build time changes are a major issue, then we may have to abandon approach 1.