Use the following to find more information about contributing to p11-kit beyond what's in this manual: Website Mailing list Issue tracker

Developers or packagers of PKCS#11 modules need to install various files into specific locations so that p11-kit will recognize and load the module correctly. You should use pkg-config as described below to determine configuration paths. p11-kit installs a pkg-config file called p11-kit-1.pc. This file contains all the information about the various paths that p11-kit looks for files at.

As described in the module configuration documentation, each PKCS#11 module should install a config file describing that module. These config files should be installed to a specific directory which can be determined by running: $ pkg-config p11-kit-1 --variable p11_module_configs /usr/share/p11-kit/modules

If a module configuration contains a relative path in its module: setting, then that module will be loaded from the default module path. This path can be determined by running: $ pkg-config p11-kit-1 --variable p11_module_path /usr/lib64/pkcs11

The p11-kit tool provides a extract-trust command which extracts trust policy information such as certificate anchors and so on into files for use with libraries that cannot read this trust information directly. In order to be useful the extract-trust command needs to be customized per distribution or site. You can find this file in at tools/p11-kit-trust-extract.in in the p11-kit source code. The command is implemented as a simple script which performs the various p11-kit extract commands necessary to extract the information. Using this script as a standard way to extract this information allows for consistency between distributions and ease of system administration.

This describes how to compiling the p11-kit package from source code. This is normally only necessary for those wishing to contribute to the project or package p11-kit. You can download tarballs of the releases of p11-kit or check out the source code from git. This documentation will not go into all the details of how to get your development environment set up and instead focus on the what's unique to compiling p11-kit.

p11-kit uses the standard GNU build system, using autoconf for package configuration and resolving portability issues, automake for building makefiles that comply with the GNU Coding Standards, and libtool for building shared libraries on multiple platforms. The normal sequence for compiling and installing the p11-kit library is thus: $ ./configure --prefix=/path/to/prefix ... $ make $ make install If you've checked out the source code from git, then the configure script does not yet exist. So use the following instead: $ ./autogen.sh --prefix=/path/to/prefix ... $ make $ make install The standard options provided by GNU autoconf may be passed to the configure script. Please see the autoconf documentation or run ./configure --help for information about the standard options. In particular you probably want to adjust the --prefix=/xxx argument depending on your system and development environment.

On a modern GNU Linux system, p11-kit has no required dependencies other than the standard C library. However on older UNIX systems, some of the following may be required. gettext is required if your system doesn't have the gettext() functionality for handling message translation databases. This can be provided by the libintl library from the GNU gettext package. pthread is required if your (ancient) system doesn't have this included in the base system. How this is provided is platform specific. In addition p11-kit has several optional dependencies. If these are not available during the build, then certain features will be disabled. libffi for sharing of PKCS#11 modules between multiple callers in the same process. It is highly recommended that this dependency be treated as a required dependency. gtk-doc is required to build the reference manual. Use --enable-doc to control this dependency. xsltproc is required to build the command manual pages. Use --enable-doc to control this dependency. libtasn1 is required to build the trust module and code that interacts with certificates. freebl3 (developed as part of the NSS code base) is an optional dependency that may be used to meet policy requirements of system builders. Enabling this dependency provides no other advantage.

In addition to the normal options, the configure script in the p11-kit library supports these additional arguments: --disable-trust-module Disables building of the trust policy module. --disable-debug, --enable-debug By default p11-kit is built with debug symbols assertions and and precondition checks. Enabling the debug option configures even more detailed debug build, including disabling optimization. Disabling the debug option is not recommended, as it disables all assertions, preconditions and internal consistency checks, although it may result it a slightly faster library. --enable-doc Enables building of the documentation and command line manual. The documentation is built in the doc/html/ directory of the build. Requires the gtk-doc and xsltproc dependencies. --enable-strict Enables strict checks during building of p11-kit. All compiler warnings become errors. --with-hash-impl=freebl Instead of using internal hash code, link to the freebl3 library and use its hash implementations. The only advantage this brings is to meet the policy requirements of system builders. --with-libtasn1, --without-libtasn1 Build with a dependency on the libtasn1 library. This dependency allows the trust policy module to be built as well as other code that interacts with certificates. --with-module-path Specify the path to look for PKCS#11 modules which were listed in a module config file with a relative path. --with-trust-paths Specify the files or directories to look for certificate anchors and blacklists. Multiple files and/or directories are specified with a : in between them. The first path has the highest priority when searching for certificates. --with-system-config Specify the path to look for p11-kit config files. This usually defaults to something like /etc/pkcs11 --with-user-config Specify the path to look for user specific p11-kit config files. If specify a path that begins with ~/ then this is expanded to the home directory of the user running p11-kit. If you specify a path that begins with ~/.config/ then this is expanded to the $XDG_CONFIG_HOME directory, as outlined in the XDG Base Dir specification. This option defaults to ~/.pkcs11

We use a code style similar to the linux kernel. Use tabs to indent and spaces to align/wrap beyond the indentation level. We don't try to guarantee completely robust and problem free behavior in cases where the caller or system isn't behaving. We consider these to be outside of our control: Broken input from callers. We use preconditions to check input and immediately return. We don't try to provide error codes for all the various ways callers can screw around. Out of memory. It is pretty much impossible to handle out of memory errors correctly. Handling them alongside other errors is naive and broken. We don't try to guarantee library state (such as locks or memory leaks) when memory allocation fails. We do check the results from all memory allocations, but treat them as unexpected conditions. As a nod to the behavior of callers of this library, we don't abort on memory allocation failures. We use preconditions with somewhat sane results. Exception: when reading files or allocating potentially unbounded amounts of memory, we should respond robustly to memory allocation failures. These unexpected conditions indicate a bug either in p11-kit or in the system. All bets are off once this occurs. Use the return_val_xxx() precondition macros to check for unexpected conditions.

As a general rule changes to p11-kit should have a tests exercising that change. Use the make check command to run all the tests. If you run it from a subdirectory only the tests in that directory will be run. To check for memory errors or memory leaks, run make memcheck or make leakcheck respectively. This requires valgrind be installed. Build p11-kit with the --enable-coverage configure option to build code coverage support. Once you've done that you can either use make coverage to build code coverage information. Alternatively (and this is usually easier) you can use git coverage to easily check whether you've tested the lines changed by a patch. A code coverage report is available online.

Unexpected conditions will produce critical warnings by p11-kit. These are often failed internal preconditions, and usually indicate a bug either in p11-kit or the software calling it. You can use the environment variable P11_KIT_STRICT=yes to make p11-kit do an abort() (and core dump depending on your configuration) when a critical warning occurs.