Patch by Andrew Cagney Preliminary Review by Ryan Sleevie Tested against all.sh rrelyea. r=kjacobs (this bug is old) pkix_Build_GatherCerts() has two code paths for creating the list "certsFound": pkix_CacheCert_Lookup() this sets "certsFound" to a new list "certsFound" and "cachedCertTable" share items but not the list pkix_CacheCert_Add(pkix_pl_Pk11CertStore_CertQuery()) this sets "certsFound" to a new list; and then adds the list to "cachedCertTable" "certsFound" and "cachedCertTable" share a linked list Because the latter doesn't create a separate list, deleting list elements from "certsFound" can also delete list elements from within "cacheCertTable". And if this happens while pkix_CacheCert_Lookup() is trying to update the same element's reference, a core dump can result. In detail (note that reference counts may occasionally seem off by 1, its because data is being captured before function local variables release their reference): pkix_Build_GatherCerts() calls pkix_pl_Pk11CertStore_CertQuery() (via a pointer) to sets "certsFound": PKIX_CHECK(getCerts (certStore, state->certSel, state->verifyNode, &nbioContext, &certsFound, plContext), PKIX_GETCERTSFAILED); it then calls: PKIX_CHECK(pkix_CacheCert_Add (certStore, certSelParams, certsFound, plContext), PKIX_CACHECERTADDFAILED);
|732252121f 3 weeks ago|
|automation||2 weeks ago|
|cmd||2 weeks ago|
|coreconf||2 months ago|
|cpputil||2 months ago|
|doc||1 year ago|
|fuzz||1 year ago|
|gtests||2 weeks ago|
|lib||2 weeks ago|
|nss/automation/abi-check||11 months ago|
|nss-tool||7 months ago|
|pkg||4 years ago|
|tests||2 weeks ago|
|.arcconfig||2 years ago|
|.clang-format||4 years ago|
|.gitignore||3 years ago|
|.hgignore||3 years ago|
|.hgtags||2 weeks ago|
|.sancov-blacklist||2 years ago|
|.taskcluster.yml||1 year ago|
|COPYING||8 years ago|
|Makefile||2 months ago|
|build.sh||2 months ago|
|exports.gyp||2 years ago|
|help.txt||1 year ago|
|mach||1 year ago|
|manifest.mn||2 months ago|
|nss.gyp||2 months ago|
|readme.md||2 months ago|
|trademarks.txt||8 years ago|
Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. NSS supports TLS 1.2, TLS 1.3, PKCS #5, PKCS#7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards.
This particular fork of NSS caters specifically to inclusion of NSS in the build system of the Unified XUL Platform (UXP) and is patched to build as part of the Mozilla build system version in use in UXP. While this should work fine for inclusion in other environments, please be aware that it may have some issues performing builds in parallel jobserver mode (-j) if trying to build standalone or as part of a tree.
Aside from the build system changes there are no significant other changes made and the repo will fully mirror official NSS development otherwise.
In order to get started, create a new directory that you will be using as your local work area, and check out NSS and NSPR. (Note that there’s no git mirror of NSPR and you require mercurial to get the latest NSPR source.)
git clone https://repo.palemoon.org/MoonchildProductions/NSS.git hg clone https://hg.mozilla.org/projects/nspr
After changing into the NSS directory a typical build of 32-bit NSS is done as follows:
The following environment variables might be useful:
BUILD_OPT=1 to get an optimised build
USE_64=1 to get a 64-bit build (recommended)
The complete list of environment variables can be found here.
To clean the build directory run:
Make sure that the address
$HOST.$DOMSUF on your computer is available. This
is necessary because NSS tests generate certificates and establish TLS
connections, which requires a fully qualified domain name.
You can test this by
ping $HOST.$DOMSUF. If this is working, you’re all set. If it’s not,
set or export:
Note that you might have to add
/etc/hosts if it’s not
there. The entry should look something like
127.0.0.1 nss.local nss.
Runnning all tests will take a while!
cd tests ./all.sh
Make sure that all environment variables set for the build are set while running
the tests as well. Test results are published in the folder
Individual tests can be run with the
NSS_TESTS environment variable,
NSS_TESTS=ssl_gtests ./all.sh or by changing into the according directory
and running the bash script there
cd ssl_gtests && ./ssl_gtests.sh. The
following tests are available:
cipher lowhash libpkix cert dbtests tools fips sdr crmf smime ssl ocsp merge pkits chains ec gtests ssl_gtests bogo policy
To make tests run faster it’s recommended to set
NSS_CYCLES=standard to run
only the standard cycle.
NSS releases can be found in the releases section of this repo. We do not provide pre-built binaries. Because NSS depends on the base library NSPR you should download the appropriate archive of NSPR alongside NSS. Releases will list the version of NSPR they need as a companion.
Directly contributing to this repo is not useful. If you wish to contribute to NSS development please get involved with the Mozilla NSS team, instead. The only exception would be any contributions needed for our particular integration into UXP that divert from upstream.
Bugzilla is used to track NSS development and bugs. File new bugs in the NSS product.
A list with good first bugs to start with are listed here.
The nss directory contains the following important subdirectories:
coreconf contains the build logic.
lib contains all library code that is used to create the runtime libraries.
cmd contains a set of various tool programs that are built with NSS. Several
tools are general purpose and can be used to inspect and manipulate the
storage files that software using the NSS library creates and modifies. Other
tools are only used for testing purposes.
gtests contain the NSS test suite. While
test contains shell
scripts to drive test programs in
gtests holds a set of
A more comprehensible overview of the NSS folder structure and API guidelines can be found here.
NSS supports build configurations for FIPS-140 compliance, and alternative build configurations that disable functionality specific to FIPS-140 compliance.
This section documents the environment variables and build parameters that control these configurations.
The C macro NSS_NO_INIT_SUPPORT controls the FIPS startup self tests. If NSS_NO_INIT_SUPPORT is defined, the startup tests are disabled.
The legacy build system (make) by default disables these tests. To enable these tests, set environment variable NSS_FORCE_FIPS=1 at build time.
The gyp build system by default disables these tests. To enable these tests, pass parameter --enable-fips to build.sh.
The C macro NSS_FIPS_DISABLED can be used to disable some FIPS compliant code and enable alternative implementations.
The legacy build system (make) never defines NSS_FIPS_DISABLED and always uses the FIPS compliant code.
The gyp build system by default defines NSS_FIPS_DISABLED. To use the FIPS compliant code, pass parameter --enable-fips to build.sh.
The NSS test suite may contain tests that are included, excluded, or are different based on the FIPS build configuration. To execute the correct tests, it’s necessary to determine which build configuration was used.
The legacy build system (make) uses environment variables to control all aspects of the build configuration, including FIPS build configuration.
Because the gyp build system doesn’t use environment variables to control the build configuration, the NSS tests cannot rely on environment variables to determine the build configuration.
A helper binary named nss-build-flags is produced as part of the NSS build, which prints the C macro symbols that were defined at build time, and which are relevant to test execution.