NSS Refactor 3 11

From MozillaWiki
Jump to: navigation, search

NSS Packaging Refactor for 3.11

The Current Dependency Tree

Current NSS dependency tree (NSS 3.11.X).

libcrmf.a

  • Built with sources in nss/lib/crmf
  • Static library only.

libsmime3.so

  • Built with sources in nss/lib/smime
  • Statically linked with objects in nss/lib/pkcs12 and nss/lib/pkcs7
  • Depends on libnss3.so
  • Depends on nspr*

libssl3.so

  • Built with sources in nss/lib/ssl
  • Statically linked with library libreebl.a (nss/lib/freebl^)
  • Depends on libnss3.so
  • Depends on libfreebl3.so^
  • Depends on nspr*

libnss3.so

  • Built with sources in nss/lib/nss
  • Statically linked with objects in:
    • nss/lib/certhigh
    • nss/lib/cryptohi
    • nss/lib/pk11wrap
    • nss/lib/certdb
    • nss/lib/util
    • nss/lib/pki
    • nss/lib/dev
    • nss/lib/base
  • Depends libsoftokn3.so
  • Depends on nspr*

libsoftokn3.so

  • Built with sources in nss/lib/softoken
  • Statically linked with libraries:
    • libsecutil.a (nss/lib/util)
    • libdbm.a (dbm)
    • libfreebl.a (nss/lib/freebl^)
  • Depends on libfreebl.so^
  • Depends on nspr*
^NOTE: Freebl dependency is dynamically loaded with DLopen and won't show up
on a normal dependency list.

libfreebl.so

  • Built with soruces in nss/lib/freebl
  • Statically linked with libraries:
    • libsecutil.a (nss/lib/util)
    • libdbm.a (dbm)

libnssckbi.so

  • Built with sources in nss/lib/ckfw/builtins
  • Statically linked with libraries:
    • libnssckfw.a (nss/lib/ckfw)
    • libssb.a (nss/lib/base)
  • Depends on nspr*

Analysis

For the most part these are pretty much straight line dependencies, distinct dependencies.

The exceptions are nss/lib/base, nss/lib/util and nss/lib/freebl.

nss/lib/freebl

nss/lib/freebl is really a static binding to a loader function with an explicit dynamic load, so in practice there is very little in freebl that is actually 'copied' between components. It can really be considered a shared library dependency even though it won't show up on an ldd.

nss/lib/base

nss/lib/base is used in both libnss3.so and libckbi.so. This is the only runtime dependency libckbi.so has on the rest of NSS. Unfortately nss/lib/base depends on some headers in nss/lib/util, and nss/lib/ckfw depends on some headers in nss/lib/softoken.

nss/lib/base is one of the slowest changing directories in the NSS tree. Since NSS 3.9 there have been a grand total of 4 changes made to that tree:

  1. Between 3.9 and 3.10 the license changed from dual to tri-license.
  2. Between 3.9 and 3.10 two pointers were changed from &pointer[offset] to pointer+offset (offset was negative, and the new code is more readable).
  3. Between 3.11.2 and 3.11.3 alex fixed a null dereference bug.
  4. Between 3.11 and 3.12 whatnspr.c was removed.

nss/lib/util

nss/lib/util is used by libnss3.so, libsoftkn3.so and libfreebl3.so. Besides the copy issue, util also creates an issue for libsoftkn3.so and libfreebl3.so because the latter are FIPS modules. Changes to nss/lib/util technically affect the FIPS validation. Since nss/lib/util does not participate in the management of CPS, it is usually possible to reinstate the validation with a review and letter from the lab.

ckfw/nssckbi dependencies

Besides the object code dependencies, there are some unexpected build dependencies for ckfw.

If you try the following:

 # get ckfw
 cvs checkout -r NSS_3_11_BRANCH mozilla/security/coreconf \
       mozilla/security/nss/lib/base mozilla/security/nss/lib/ckfw
 # get nspr
 cvs checkout mozilla/nsprpub
 cvs checkout -r NSS_3_11_BRANCH mozilla/security/nss/Makefile \
       mozilla/security/nss/manifest.mn
 #build dependencies
 cd mozilla/security/nss
 make build_coreconf build_nspr
 #build base
 cd lib/base
 make
 #build ckfw
 cd ../ckfw
 make

You find the lib/base will fail because it needs header files supplied out of lib/util and lib/ckfw will fail because it needs header files supplied out of softoken (the pkcs11 headers).

Recommendation

Because of the static linking issue for NSS 3.11.x we should support the following:

  1. nssckbi.so built in it's own 3.11.x tree used in other versions of NSS 3.11.x.
  2. softoken.so/freebl.so built in an NSS 3.11.4 tree used with other versions of NSS 3.11.x (x > 4).
  3. nssckbi.so where the ckfw directory is built from a newer version of NSS 3.11.x, used in an older version of NSS 3.11.x
  4. fips validated versions of softoken freebl built in a newer nss tree where the new version of util in that tree has been validated with a letter from the lab.

Open Questions. Should we tag blessed combinations with special tags, or document which component mixing is approved?