Created attachment 417320 [details] [diff] [review] 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.
Created attachment 420822 [details] [diff] [review] 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.
Attachment #417320 - Attachment is obsolete: true
Created attachment 420861 [details] [diff] [review] 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.
Attachment #420822 - Attachment is obsolete: true
wtc: we're interested in these patches for Firefox (bug 561842). Is there anything I can do to help you move this work along?
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.
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.
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.
Another popular system with no mmu is the Lantronix Xport pro, which is where we ran into this issue for libreswan
You need to log in before you can comment on or make changes to this bug.