e4e3559e1b
2020-04-24 Kevin Jacobs <kjacobs@mozilla.com>
* automation/abi-check/expected-report-libnss3.so.txt,
gtests/softoken_gtest/softoken_gtest.cc, lib/nss/nss.def,
lib/pk11wrap/pk11obj.c, lib/pk11wrap/pk11pub.h, lib/softoken/sdb.c:
Bug 1612881 - Maintain PKCS11 C_GetAttributeValue semantics on
attributes that lack NSS database columns r=keeler,rrelyea
`sdb_GetAttributeValueNoLock` builds a query string from a list of
attributes in the input template. Unfortunately,
`sqlite3_prepare_v2` will fail the entire query if one of the
attributes is missing from the underlying table. The PKCS #11 spec
[[ https://www.cryptsoft.com/pkcs11doc/v220/pkcs11__all_8h.html#aC_G
etAttributeValue | requires ]] setting the output `ulValueLen` field
to -1 for such invalid attributes.
This patch reads and stores the columns of nssPublic/nssPrivate when
opened, then filters an input template in
`sdb_GetAttributeValueNoLock` for unbacked/invalid attributes,
removing them from the query and setting their template output
lengths to -1.
[aae226c20dfd] [tip]
2020-04-23 Kevin Jacobs <kjacobs@mozilla.com>
* lib/ssl/sslnonce.c:
Bug 1531906 - Relax ssl3_SetSIDSessionTicket assertions to permit
valid, evicted or externally-cached sids. r=mt
This patch relaxes an overzealous assertion for the case where: 1)
Two sockets start connections with a shared SID. 2) One receives an
empty session ticket in the SH, and evicts the SID from cache. 3)
The second socket receives a new session ticket, and attempts to set
it in the SID.
We currently assert that the sid is `in_client_cache` at 3), but
clearly it cannot be. The outstanding reference remains valid
despite the eviction.
This also solves a related assertion failure after
https://hg.mozilla.org/mozilla-central/rev/c5a8b641d905 where the
same scenario occurs, but instead of being `in_client_cache` or
evicted, the SID is `in_external_cache`.
[a68de0859582]
2020-04-16 Robert Relyea <rrelyea@redhat.com>
* gtests/common/testvectors/kwp-vectors.h,
gtests/pk11_gtest/manifest.mn,
gtests/pk11_gtest/pk11_aeskeywrapkwp_unittest.cc,
gtests/pk11_gtest/pk11_gtest.gyp, lib/freebl/aeskeywrap.c,
lib/freebl/blapi.h, lib/freebl/blapit.h, lib/freebl/hmacct.c,
lib/freebl/ldvector.c, lib/freebl/loader.c, lib/freebl/loader.h,
lib/pk11wrap/pk11mech.c, lib/softoken/lowpbe.c,
lib/softoken/pkcs11.c, lib/softoken/pkcs11c.c,
lib/softoken/pkcs11i.h, lib/softoken/pkcs11u.c, lib/ssl/ssl3con.c,
lib/util/secport.h:
Bug 1630721 Softoken Functions for FIPS missing r=mt
For FIPS we need the following:
1. NIST official Key padding for AES Key Wrap. 2. Combined
Hash/Sign mechanisms for DSA and ECDSA.
In the first case our AES_KEY_WRAP_PAD function addes pkcs8 padding
to the normal AES_KEY_WRAP, which is a different algorithm then the
padded key wrap specified by NIST. PKCS #11 recognized this and
created a special mechanism to handle NIST padding. That is why we
don't have industry test vectors for CKM_NSS_AES_KEY_WRAP_PAD. This
patch implements that NIST version (while maintaining our own). Also
PKCS #11 v3.0 specified PKCS #11 mechanism for AES_KEY_WRAP which
are compatible (semantically) with the NSS vendor specific versions,
but with non-vendor specific numbers. Softoken now accepts both
numbers.
This patch also updates softoken to handle DSA and ECDSA combined
hash algorithms other than just SHA1 (which is no longer validated).
Finally this patch uses the NIST KWP test vectors in new gtests for
the AES_KEY_WRAP_KWP wrapping algorithm.
As part of the AES_KEY_WRAP_KWP code, the Constant time macros have
been generalized and moved to secport. Old macros scattered
throughout the code have been deleted and existing contant time code
has been updated to use the new macros.
[3682d5ef3db5]
2020-04-21 Lauri Kasanen <cand@gmx.com>
* lib/freebl/Makefile, lib/freebl/freebl.gyp,
lib/freebl/freebl_base.gypi, lib/freebl/gcm.h, lib/freebl/ppc-
crypto.h, lib/freebl/scripts/LICENSE, lib/freebl/scripts/gen.sh,
lib/freebl/scripts/ppc-xlate.pl, lib/freebl/scripts/sha512p8-ppc.pl,
lib/freebl/sha512-p8.s, lib/freebl/sha512.c:
Bug 1613238 - POWER SHA-2 digest vector acceleration. r=jcj,kjacobs
[2d66bd9dcad4]
2020-04-18 Robert Relyea <rrelyea@redhat.com>
* coreconf/Linux.mk, coreconf/config.gypi, lib/softoken/sdb.c:
Bug
|
||
|---|---|---|
| .. | ||
| automation | ||
| cmd | ||
| coreconf | ||
| cpputil | ||
| doc | ||
| fuzz | ||
| gtests | ||
| lib | ||
| nss/automation/abi-check | ||
| nss-tool | ||
| pkg | ||
| tests | ||
| .arcconfig | ||
| .clang-format | ||
| .gitignore | ||
| .sancov-blacklist | ||
| .taskcluster.yml | ||
| build.sh | ||
| COPYING | ||
| exports.gyp | ||
| help.txt | ||
| mach | ||
| Makefile | ||
| manifest.mn | ||
| nss.gyp | ||
| readme.md | ||
| TAG-INFO | ||
| trademarks.txt | ||
Network Security Services
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.
Getting started
In order to get started create a new directory on that you will be uses 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://github.com/nss-dev/nss.git
hg clone https://hg.mozilla.org/projects/nspr
NSS can also be cloned with mercurial
hg clone https://hg.mozilla.org/projects/nss
Building NSS
This build system is under development. It does not yet support all the features or platforms that NSS supports. To build on anything other than Mac or Linux please use the legacy build system as described below.
Build requirements:
After changing into the NSS directory a typical build is done as follows
./build.sh
Once the build is done the build output is found in the directory
../dist/Debug for debug builds and ../dist/Release for opt builds.
Exported header files can be found in the include directory, library files in
directory lib, and tools in directory bin. In order to run the tools, set
your system environment to use the libraries of your build from the "lib"
directory, e.g., using the LD_LIBRARY_PATH or DYLD_LIBRARY_PATH.
See help.txt for more information on using build.sh.
Building NSS (legacy build system)
After changing into the NSS directory a typical build of 32-bit NSS is done as follows:
make nss_build_all
The following environment variables might be useful:
-
BUILD_OPT=1to get an optimised build -
USE_64=1to get a 64-bit build (recommended)
The complete list of environment variables can be found here.
To clean the build directory run:
make nss_clean_all
Tests
Setup
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
calling ping $HOST.$DOMSUF. If this is working, you're all set. If it's not,
set or export:
HOST=nss
DOMSUF=local
Note that you might have to add nss.local to /etc/hosts if it's not
there. The entry should look something like 127.0.0.1 nss.local nss.
Running tests
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
../../test_results/.
Individual tests can be run with the NSS_TESTS environment variable,
e.g. 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.
Releases
NSS releases can be found at Mozilla's download server. Because NSS depends on the base library NSPR you should download the archive that combines both NSS and NSPR.
Contributing
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.
NSS Folder Structure
The nss directory contains the following important subdirectories:
-
coreconfcontains the build logic. -
libcontains all library code that is used to create the runtime libraries. -
cmdcontains 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. -
testandgtestscontain the NSS test suite. Whiletestcontains shell scripts to drive test programs incmd,gtestsholds a set of gtests.
A more comprehensible overview of the NSS folder structure and API guidelines can be found here.
Build mechanisms related to FIPS compliance
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.
Build FIPS startup tests
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.
Building either FIPS compliant or alternative compliant code
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.
Test execution
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.