Wednesday  2 October 2024


FreeBSD jails, ZFS, and Stow for building software
==================================================

I wanted to build the latest GnuPG release.

To build gnupg-2.5.1., first a number of dependencies must be build.

I build the following components:

* libassuan-3.0.1
* libgcrypt-1.11.0
* libgpg-error-1.50
* libksba-1.6.7
* npth-1.7
* ntbtls-0.3.2
* gpgme-1.23.2
* gnupg-2.5.1
* pinentry-1.3.1
  
GnuPG on FreeBSD
----------------
It is not guaranteed that GnuPG and its libraries, which were
developed on Linux, would build flawlessly on FreeBSD. The best place
for building the components is an isolated environment, to lessen the
possibility of damaging the present system. It makes perfect sense to
do this with a FreeBSD jail.

To make future updates as easy as possible, I automate the process as
much as possible, like the creation of a list of tar-balls to fetch,
fetching the tar-balls, unpacking the tar-balls, and the configure,
make, make install, and the stow commands. A jail is a great place to
create and test the scripting for this.

GNU Stow
--------
The components are first build in the jail and will be deployed on
several FreeBSD systems. The deployment can be done by building a
package. A less complicated alternative is the use of GNU Stow.

Each of the components will be installed in its own sub directory
under `/usr/local/stow', e.g., libgcrypt will be installed in
`/usr/local/stow/libgcrypt'.

Running stow will result in a number of symlinks in `/usr/local/bin',
'/usr/local/lib', and so on.

For example, after running `stow libgcrypt' and ``stow libassua' we
get the following symlinks:

|-- bin -> stow/libgcrypt/bin
|-- include
|   |-- assuan.h -> ../stow/libassuan/include/assuan.h
|   `-- gcrypt.h -> ../stow/libgcrypt/include/gcrypt.h
|-- lib
|   |-- libassuan.la -> ../stow/libassuan/lib/libassuan.la
|   |-- libassuan.so -> ../stow/libassuan/lib/libassuan.so
|   |-- libassuan.so.9 -> ../stow/libassuan/lib/libassuan.so.9
|   |-- libgcrypt.la -> ../stow/libgcrypt/lib/libgcrypt.la
|   |-- libgcrypt.so -> ../stow/libgcrypt/lib/libgcrypt.so
|   |-- libgcrypt.so.25 -> ../stow/libgcrypt/lib/libgcrypt.so.25
|   `-- pkgconfig
|       |-- libassuan.pc -> ../../stow/libassuan/lib/pkgconfig/libassuan.pc
|       `-- libgcrypt.pc -> ../../stow/libgcrypt/lib/pkgconfig/libgcrypt.pc
`-- share
    |-- aclocal
    |   |-- libassuan.m4 -> ../../stow/libassuan/share/aclocal/libassuan.m4
    |   `-- libgcrypt.m4 -> ../../stow/libgcrypt/share/aclocal/libgcrypt.m4
    |-- info
    |   |-- assuan.info -> ../../stow/libassuan/share/info/assuan.info
    |   |-- gcrypt.info -> ../../stow/libgcrypt/share/info/gcrypt.info
    |   |-- gcrypt.info-1 -> ../../stow/libgcrypt/share/info/gcrypt.info-1
    |   `-- gcrypt.info-2 -> ../../stow/libgcrypt/share/info/gcrypt.info-2
    `-- man -> ../stow/libgcrypt/share/man

To install the components on another system, we only have to copy the
stow directory to that system and issue the command `stow *'.

This is a good way to manage and deploy self compiled software.

ZFS and jails
-------------
ZFS and jails are a match made in heaven.

Just create a general jail for building software. This can be a base
jail, with some additional packages like git and stow. Configure ssh
in your user account, like an `authorized_keys' file and the required
keys.

Next, create a ZFS snapshot of the jail.

There are two different routes to go from here.

* Either you use the snapshot to create a work jail, either by ZFS clone
  of ZFS send/receive, and build the software in there. When done, copy
  the stow directory to your other systems and destroy the jail.

* Or you build the software directly in the base jail and when done,
  roll back to the snapshot.

Cloning a ZFS snapshot is instantaneously, and using ZFS send/receive
locally to create a new jail doesn't take much time.

Building GnuPG
--------------
Because of the dominance of Linux in the open source operating systems
ecosystem the penalty for deviating from common ground is less severe.

GnuPG and its components cannot be build on FreeBSD without some
patching. This time it was easy, only to add two lines, but somebody
had to discover that first. And I'm afraid this is just the beginning.

Quantum proof
-------------
The benefit of upgrading GnuPG to version 2.5.1. is that this allows
for post-quantum cryptography. With gnupg-2.5.1 you can create
quntum-proof sub keys like ky768_cv25519 to use quantum-proof
algorithms.

I added a ky768_cv25519 sub key to my key. Unfortunately, I was not
able to export the secret key, it appears this is not (yet) supported.
I prefer to have an ASCII-armored export of my secret keys, as a way
of backup. Having to rely on a copy of my `~/.snupg' directory feels a
bit scary.



Last edited: $Date: 2024/10/02 09:31:42 $