Hacking NSS: Difference between revisions

From Libreswan
Jump to navigation Jump to search
(fix link line)
(headnings)
Line 5: Line 5:
It includes both the error symbol name and the error message (the former is really useful when reading the code^D^D^D^D documentation when tracking down why the error was returned).
It includes both the error symbol name and the error message (the former is really useful when reading the code^D^D^D^D documentation when tracking down why the error was returned).


== Debugging NSS ==
== Building Libreswan using custom NSS RPMs ==


NSS_ENABLE_PKIX_VERIFY=1 LD_LIBRARY_PATH=$(cd ../dist/Debug/lib && pwd) gdb --args $(cd ../dist/Debug/bin && pwd)/certutil -V -n PasswordCert -u S -d ../tests_results/security/build.1/dbpass
=== Building NSS RPMs on the guest ===
(gdb) break PKIX_Shutdown
(gdb) break cert_VerifyCertChainPkix
 
== Using custom NSS RPMs ==
 
=== Building NSS RPMs ... ===
 
==== ... using <tt>fedpkg local</tt> and a KVM ====


Here, we use the <tt>build</tt> machine (it has lots of memory and network access) and the 9p mounted directory <tt>/pool</tt> (aka <tt>$(KVM_POOLDIR)</tt>, but /testing and /root should also work).  Just remember that any changes to build aren't permanent, we'll get to that later.
Here, we use the <tt>build</tt> machine (it has lots of memory and network access) and the 9p mounted directory <tt>/pool</tt> (aka <tt>$(KVM_POOLDIR)</tt>, but /testing and /root should also work).  Just remember that any changes to build aren't permanent, we'll get to that later.
Line 50: Line 42:
the RPMs are under <tt>x86_64</tt>.
the RPMs are under <tt>x86_64</tt>.


==== ... using <tt>fedpkg mock</tt> and the Fedora host ====
=== Building NSS RPMs on the host ===


Hmm, something goes here!
Hmm, something goes here!
Line 88: Line 80:
Tar up both the .rpm and .srpm files into a single archive and make that available.  That way, who ever downloads the archive always gets the source code.
Tar up both the .rpm and .srpm files into a single archive and make that available.  That way, who ever downloads the archive always gets the source code.


== Using a scratch NSS+NSPR build ==
== Building Libreswan using a scratch NSS+NSPR build ==


=== Scratch building NSS+NSPR ===
=== Scratch building NSS+NSPR ===
Line 129: Line 121:
  $ ./kvm sh east
  $ ./kvm sh east
  cat /proc/$(pgrep pluto)/maps | grep nss
  cat /proc/$(pgrep pluto)/maps | grep nss
= Debugging NSS =
NSS_ENABLE_PKIX_VERIFY=1 LD_LIBRARY_PATH=$(cd ../dist/Debug/lib && pwd) gdb --args $(cd ../dist/Debug/bin && pwd)/certutil -V -n PasswordCert -u S -d ../tests_results/security/build.1/dbpass
(gdb) break PKIX_Shutdown
(gdb) break cert_VerifyCertChainPkix

Revision as of 00:23, 29 October 2021

Using NSS from Pluto

use lsw_nss_error*() to report errors

It includes both the error symbol name and the error message (the former is really useful when reading the code^D^D^D^D documentation when tracking down why the error was returned).

Building Libreswan using custom NSS RPMs

Building NSS RPMs on the guest

Here, we use the build machine (it has lots of memory and network access) and the 9p mounted directory /pool (aka $(KVM_POOLDIR), but /testing and /root should also work). Just remember that any changes to build aren't permanent, we'll get to that later.

First lets set things up:

$ ./kvm sh build
build# cd /pool
build# dnf install -y fedpkg
build# cat /etc/fedora-release
Fedora release 32 (Thirty Two)
build# fedpkg clone --branch f32 --anonymous nss
build# cd nss
build# dnf builddep nss

Hack xmlto so that it doesn't try to preserve permissions when copying files within the 9p file system (remember, ./kvm uninstall install will wipe this):

build# sed -i -e 's/ -p / /' \
   /usr/share/xmlto/format/docbook/man \
   /usr/share/xmlto/format/docbook/html

hack nss.specso that it has a unique suffix:

build# sed -i -e '/Release:/ s/\([0-9]*\)%/\1_lsw%/' nss.spec
build# fedpkg verrel
nss-3.63.0-1_lsw.fc32

hobble running tests during the build (optional):

build# sed -i -e 's/bcond_without tests/bcond_with tests/' nss.spec

finally build:

build# fedpkg local --without tests:

or:

build# fedpkg prep --without tests
build# fedpkg compile --short-circuit --without tests

the RPMs are under x86_64.

Building NSS RPMs on the host

Hmm, something goes here!

fedpkg mock-config
fedpkg mockbuild

Installing the NSS RPMs (and making them stick)

The NSS RPMs can either be installed manually on build (which means they only stick around until ./kvm uninstall), or they can be made more permenant by installing them into the base domain.

To install the RPMs on the base domain, add the following lines to Makefile.inc.local:

# Prepend the directory containing the RPMs, include /
KVM_NSS_RPMDIR = /pool/nss/x86_64/
# Append the actual RPM version
KVM_NSS_VERSION = -3.63.0-1_lsw.fc32.x86_64.rpm

and then upgrade the base domain:

$ ./kvm upgrade
...
 Upgrading        : nss-util-3.63.0-1_lsw.fc32.x86_64                     1/20 
...

finally, confirm:

$ ./kvm install
$ ./kvm sh east
east# rpm -q nss
nss-3.63.0-1_lsw.fc32.x86_64

If needed, the the customized domains can be reverted. In Makefile.inc.local, comment out the lines added above, and then run:

$ ./kvm downgrade
$ ./kvm upgrade
...
 Installing       : nss-util-3.63.0-1.fc32.x86_64                       13/330 

Distributing Custom NSS RPMs

Tar up both the .rpm and .srpm files into a single archive and make that available. That way, who ever downloads the archive always gets the source code.

Building Libreswan using a scratch NSS+NSPR build

Scratch building NSS+NSPR

Setup:

$ ./kvm sh build
build# mkdir -p /pool/nss+nspr
build# cd !$
cd /pool/nss+nspr
build# dnf builddep nss
build# dnf install hg python gyp ninja-build

Hack xmlto so that it doesn't try to preserve permissions when copying files within the 9p file system (remember, ./kvm uninstall install will wipe this):

build# sed -i -e 's/ -p / /' \
   /usr/share/xmlto/format/docbook/man \
   /usr/share/xmlto/format/docbook/html

Using Building NSS as a guide:

build# hg clone https://hg.mozilla.org/projects/nspr
build# hg clone https://hg.mozilla.org/projects/nss
build# ./nss/build.sh --enable-libpkix

testing (for comparison, NSS build farm):

build# HOST=localhost DOMSUF=localdomain USE_64=1 nss/tests/all.sh

however, of most interest is PKIX:

( cd nss/tests/cert/ ; USE_64=1 NSS_ENABLE_PKIX_VERIFY=1 DOMSUF=localdomain ./cert.sh )

Linking with libreswan

finally, to link nss against the build, add the following to Makefile.inc.local (how correct is this?):

NSSDIR = /pool/nss+nspr
NSS_LIBDIR = $(NSSDIR)/dist/Debug/lib/
NSS_CFLAGS = -I$(NSSDIR)/nspr/Debug/dist/include/nspr -I$(NSSDIR)/dist/public/nss
NSS_LDFLAGS = -L$(NSS_LIBDIR) -Wl,-rpath,$(NSS_LIBDIR) -lnss3

and then build as per normal:

$ ./kvm install check

and confirm it worked:

$ ./kvm sh east
cat /proc/$(pgrep pluto)/maps | grep nss

Debugging NSS

NSS_ENABLE_PKIX_VERIFY=1 LD_LIBRARY_PATH=$(cd ../dist/Debug/lib && pwd) gdb --args $(cd ../dist/Debug/bin && pwd)/certutil -V -n PasswordCert -u S -d ../tests_results/security/build.1/dbpass
(gdb) break PKIX_Shutdown
(gdb) break cert_VerifyCertChainPkix