office-gobmx/nss
Tomas Chvatal f6f5c89259 Rename --enable-nss-module to --with-system-nss + introduce --enable-xmlsec.
This also finishes the uncoupling of NSS from the --with-system-mozilla.
2011-11-02 17:37:53 +01:00
..
prj deliver libcrmf.a 2011-09-14 17:05:17 -05:00
makefile.mk Rename --enable-nss-module to --with-system-nss + introduce --enable-xmlsec. 2011-11-02 17:37:53 +01:00
nss-config.patch Fix building moz on Mac OS X. 2011-09-28 13:54:24 +02:00
nss-linux3.patch nss: replace Linux 3.0 workaround with one for 3.x 2011-10-11 18:07:47 +02:00
nss.aix.patch Upgrade nss to the latest release 2010-10-21 11:58:28 +02:00
nss.patch nss: replace Linux 3.0 workaround with one for 3.x 2011-10-11 18:07:47 +02:00
nss.patch.mingw jl153 #i111877# MinGW patch for nss from tono 2010-06-21 10:36:29 +02:00
nss_macosx.patch Upgrade nss to the latest release 2010-10-21 11:58:28 +02:00
readme.txt Rename --enable-nss-module to --with-system-nss + introduce --enable-xmlsec. 2011-11-02 17:37:53 +01:00

Relation between nss, moz, moz_prebuilt
---------------------------------------
nss containes the security libraries which are also part of moz. However nss is
meant to be more current, that is it to be updated more often. This should be
easier than doing this with moz. 

If nss is build depends on an environment variable (SYSTEM_NSS=NO) which
is per default set to YES. In this case nss is build before moz. The nss
libraries/lib files/headers built in moz are then not delivered. Otherwise they
would overwrite those from nss. That is, the nss libraries build in moz are
removed from mozruntime.zip (build in moz/solver/bin), they are removed from the
lib directory (for example moz/unxlngi6.pro/lib), and the nss and nspr headers
are also removed (inc/nss and inc/nspr).  The nss libraries from the nss module
are then added to mozruntime.zip.

This also applies for moz_prebuilt. Therefore moz and moz_prebuilt must be build
again after changes have been made to the libraries in the nss module.

Also when moz was updated to use a newer version of mozilla, then one must make
sure that new files which also belong to nss are not delivered and are removed
from mozruntime.zip.

Fips 140 and signed libraries
-------------------------------
Fips 140 mode is not supported. That is, the *.chk files containing the
checksums for the cryptographic module are not delivered into solver and will
not be part of the OOo installation sets.

Signing has been turned off because 
- we change the rpath (install names)  after signing which breaks the signatures
(Mac)
- sqlite conflicts with the system sqlite when signing which breaks the build


libfreebl3
----------
Porting to other platforms may require to deliver other variants of
libfreebl*. The library name varies according to the platform. Changes need to
be made to 
ooo/moz/extractfiles.mk
ooo/moz/zipped/makefile.mk
sun/moz_prebuilt/zipped/makefile.mk

See also
http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn6.html


Windows builds of nss
---------------------
To build mozilla on windows you'll need the mozilla build tools

Build requirements containing the link to the build tools:
https://developer.mozilla.org/en/Windows_Build_Prerequisites#ss2.2

The direct link:

http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-1.3.exe

libsqlite3
----------
The problem described here was found on Mac with OS 10.6
NSS cannot use the system sqlite on Mac because the base line is still MacOS
10.4. That system sqlite is incompatible with the softokn3 in nss which requires
a later version of sqlite. 
When we used a more current Mac SDK then we could set 
NSS_USE_SYSTEM_SQLITE=1
to build using the system sqlite.

We cannot deliver sqlite in the lib directory of the solver. This directory is
used by tools of the build environment. Using the sqlite from NSS breaks the
tools if they use system libraries which are linked with the system
sqlite. Therefore we deliver it into lib/sqlite on unix systems.

See also issue 
http://qa.openoffice.org/issues/show_bug.cgi?id=106132