534471 - Patches for using NSS as static libraries

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P5)

Description

[Wan-Teh Chang]

Attachment: Patch (nssckbi still a shared library)

I'm using this bug report to publish patches that enable
using NSS as static libraries.

WARNING: NSS is FIPS validated in shared library form only.
If you're using NSS for its FIPS validation, do *not* use
NSS as static libraries.

WARNING: NSS uses shared libraries heavily.  The NSS team
only supports NSS in shared library form.  I'm providing
these patches without support.  The patches in this bug
could be hard to maintain as NSS evolves.

This bug requires the patches in NSPR bug 533014 for building
NSPR as static libraries.

The attached patch enables you to build NSS (except the nssckbi
shared library) as static libraries.  I've tested it on Mac OS
X and Windows.  (On Linux there is little reason to use NSS as
static libraries because NSS is available as system libraries.)

I created this patch as follows:

1. Search for "declspec", "dllimport", "dllexport" in the source
tree to make sure no symbols are exported from Windows DLLs with
__declspec(dllexport).

2. Search for "PORT_Load", "PR_Load", "PR_Find", "LoadLibrary",
"GetProcAddress" in the source tree.  These strings are the
(prefixes of) names of NSPR and Win32 functions that load
libraries and look up exported symbols.

3. lib/freebl requires special attention because the actual code
is a shared library and the static library is a simple loader.c
file that loads the shared library and dispatches calls to it.
The patch needs to build the actual code as a static library.
Fortunately the solution turned out to be simpler than I expected.

4. lib/softoken loads libnssdbm3 (the "legacy DB" library).  This
needs to be replaced by static wiring (see lgglue.h and lgglue.c).

My patch has an option (search for TRY_TO_USE_NSSDBM) to omit
libnssdbm3 if you don't need legacy DB support.  I leave libnssdbm3
in by default so that I can run the NSS test suite (which still
uses legacy DB).

5. The FIPS software integrity test can't be performed on static
libraries.  My patch has a PSEUDO_FIPS option to use NSS static
libraries in *pseudo* FIPS mode.  In the pseudo FIPS mode, the
FIPS software integrity test is disabled.  This allows the NSS
softoken to follow all the other FIPS requirements.

6. lib/pk11wrap loads libsoftokn3.  This needs to be replaced by
static wiring (see pk11load.c).

7. My patch has a NO_LIBPKIX option to omit lib/libpkix.  Although
libpkix is brand new, it will replace the current certificate
verification code, so I don't recommend you omit lib/libpkix.  But
if you don't use libpkix (the CERT_PKIXVerifyCert function), you can
enable the NO_LIBPKIX option to omit a lot of code.

8. We should be able to build nssckbi as a static library.  I
didn't do it because I don't need it, not because it can't be done.

9. Some of the changes in this patch are not specific to using
NSS as static libraries.  I'll get those changes reviewed and
checked in to make this patch smaller.

Comment 1

[Wan-Teh Chang]

Attachment: Patch (nssckbi still a shared library) v2

I updated the patch to the current NSS trunk as some of the
generally useful changes in my patch have been checked in.

Comment 2

[Wan-Teh Chang]

Attachment: Patch (nssckbi still a shared library) v3

Use NO_LIBPKIX consistently to mark the places that need changing
if we want to omit libpkix.

Improve the TRY_TO_USE_NSSDBM related code in lib/softoken/lgglue.c,
and mark all the places that need changing if we want to omit libnssdbm.

Comment 3

[(not currently active) Ted Mielczarek]

wtc: we're interested in these patches for Firefox (bug 561842). Is there anything I can do to help you move this work along?

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Ted:

My understanding is that it is too late to do this for FF4 so I haven't spent much time looking into it. But, I did speak with Wan-Teh about his patches and he pointed out some reasons why his patches are appropriate for Chrome but not for Firefox. Wan-Teh said he posted this patch simply to comply with the terms of the NSS licenses, and not because it is acceptable for other uses outside of Chrome.

I also reached some agreement with others on the NSS team on the general idea of having some support for us to statically link some or all of NSS into libxul in the NSS trunk, as long as we retained support for NSS as shared libraries on desktop Linux, where Android and Maemo are not considered Desktop Linux. Wan-Teh and Robert Relyea both stated that they expect that keeping NSS as shared libraries on desktop Linux would be better for performance if we can use the system NSS libraries. And, also, Red Hat has some business needs for Firefox using system-provided NSS shared libraries instead of its own. 

It looks quite simple to link almost all of NSS into libxul, except for Softoken & FreeBL. But, Wan-Teh's patch is probably not so useful to use as the foundation for a patch to enable that, AFAICT, since we also want to enable incremental linking of libxul with compilers that do incremental linking when a static library changes.

Please feel free to ping me about this when you are interested in seeing it happen in FF as I have also done some experiments in this area.

Comment 5

[Tolga Tarhan]

wtc/Brian:

Has anyone produced an updated patch suitable for use with the newest NSS, or is there some other way to use NSS when it's built statically? Based on the current NSS trunk, it seems that building the static libraries is no problem but using NSS when it's built statically doesn't work. Specifically, secmod_LoadPKCS11Module fails as expected, and then the NSS library is not properly initialized.

While I understand that the desire is to encourage use of NSS as a shared library, there are some platforms where this is simply not possible. A good example being iOS. Bug 680878 made compiling for iOS possible, but I don't see how the output of such a build could ever be used in the iOS environment where we don't have dynamic loading.

Comment 6

[Ryan Sleevi]

Chromium continues to build NSS statically on (Mac, Windows, iOS). The patched copy of NSS minus-libssl is at http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/nss/ , with libssl-alone at http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/ 

http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/nss/patches/nss-static.patch?revision=169374&view=markup is the static patch - which has 3 defines - NSS_STATIC, NSS_DISABLE_LIBPKIX, and NSS_DISABLE_ROOT_CERTS

On iOS, Chromium uses NSS's root store + libpkix, since the system certificate verification APIs are so limited. Depending on your use case, it may or may not be appropriate to use the system APIs instead.

Comment 7

[Paul Wouters]

Another popular system with no mmu is the Lantronix Xport pro, which is where we ran into this issue for libreswan

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.