Firefox allows installing PKCS#11 modules via Enterprise Policy. It would be useful to test this on Cirrus, for all supported OS's (Windows, macOS, GNU/Linux). Probably the easiest way to test it given the current test structure is to install pkcs11proxy via Enterprise Policy with tracing turned on, and check to make sure the trace log gets created.

p11tool is the GnuTLS equivalent of NSS's certutil. We should add tests for it, by having it open modules via pkcs11proxy and p11proxy and making sure the behavior doesn't change.

We currently test OpenDNSSEC with pkcs11proxy, but not p11proxy. We should add tests for p11proxy with OpenDNSSEC.

We should test Tor Browser.

Looks like our Makefile doesn't use CFLAGS. We might need to fix that.

Currently our build scripts use the format libXXX.so on all platforms. On Windows, this should be XXX.dll, i.e. change the extension and remove the lib prefix.

According to Dependencies, pkcs11proxy.dll is not exporting C_GetFunctionList on Windows. This is probably why I can't get the module to load in Firefox and certutil on Windows. Probably this is due to the changes introduced by golang/go#30674 , which makes sense given that this worked a few years ago.

Potential places to look:

• Search GitHub or https://sources.debian.org/ or https://searchfox.org/ for C_GetFunctionList and other PKCS#11 function names (especially function names that we currently don't implement in p11mod).
• Search GitHub or package repos or Repology for pkcs11 or p11.
• Search the dependency graph for other software that uses the PKCS#11 libs that are used in our current tests.

Once you find something, create an issue, or jump right in and add integration tests in a PR. If your integration tests don't pass (perhaps because of a bug in pkcs11mod) but you believe they are useful, that's fine, you can submit them anyway, and we can just instruct Cirrus to allow failure on them.

Debian's p11-kit situation is less mature than Fedora's, so worth testing there.

The log file paths in init() should really be part of the backend implementation (e.g. ncp11), not pkcs11mod.

As described in the README, pkcs11mod supports a "trace" feature, which is useful for debugging. Currently we trace the values of attributes as byte slices. For attributes of type CKA_CLASS, it would be desirable to trace their values as friendly CKO_ names, like how we currently trace friendly CKA_ names.

@aerth @bernard-wagner are you okay with relicensing pkcs11mod (and ncp11) from LGPLv3+ to LGPLv2+? This would allow pkcs11mod to be used with applications licensed under GPLv2. While I am personally very skeptical that loading a PKCS#11 module into an application is legally capable of creating a derivative work (I think PKCS#11 is an interface, so a copyright license like GPL cannot jump across it), there is not much (if any?) case law on this, and the legal uncertainty is not really desirable for us. Also it's not great that pkcs11mod is more compatible with non-free software than with GPLv2 software.

Currently, we test Linux-distro-packaged Chromium on Cirrus. It would be desirable to test other Chromium variants. An unsorted list of potential Chromium variants to test:

• Google Chrome
• Google Chrome Dev
• Google Chrome Beta
• Chromium Nightly
• Opera
• Brave
• Electron
• Beaker
• https://www.startpage.com/do/search?q=list+of+chromium+forks&rl=to
  • Iridium Browser
  • https://wiki.installgentoo.com/index.php/Web_browsers
  • https://en.wikipedia.org/wiki/List_of_web_browsers
  • Slimjet
  • https://alternativeto.net/software/chromium/?platform=linux
• https://github.com/nylira/prism-break/search?q=browser&type=Issues&utf8=%E2%9C%93
  • ungoogled-chromium
    • Inox patchset
  • Sware Iron
    • Epic Privacy Browser
  • Midori
  • WhiteHat Aviator
  • Yandex
  • QupZilla
  • Comodo Dragon

We should test what happens if two PKCS#11 modules that are both created via pkcs11mod are loaded simultaneously by the same application. (It is conceivable that their Go runtimes might conflict.)

We should implement GetMechanismList in p11mod.

We should consider logging the PID (os.Getpid()) and process name (os.Args[0] and os.Executable()). This would help for debugging things such as Chromium-specific "built-in trust anchor" disabling, and per-process Tor stream isolation. Maybe also the thread ID (syscall.Gettid()).

We should test NSS tstclnt on Windows. This would be easier if tstclnt binaries were readily available.

Running strace gnutls-cli www.namecoin.org on Fedora 34 finds a bunch of references to PKCS#11 modules, including p11-kit-trust.so. These references don't appear on Debian 11, which seems to indicate that PKCS#11 is not being used for certificate trust in GnuTLS on Debian. This might be related to Debian not using the --with-default-trust-store-pkcs11=pkcs11: configure flag. However, on Debian, the library libp11-kit.so.0 is loaded, which might indicate some kind of p11-kit misconfiguration rather than a GnuTLS issue. Not sure. We should investigate further. The p11-kit devs might be able to help.

Softoken is the NSS mutable (sqlite-based) certificate database PKCS#11 module. We should add tests for it, by putting it behind pkcs11proxy and p11proxy and making sure the behavior doesn't change.

wget appears to use GnuTLS, so we should be able to test it easily.

It would be helpful for debugging purposes if pkcs11mod and p11mod could log traces of which functions are being called, with what arguments. This could be enabled via an environment variable. Such functionality is a privacy risk (e.g. it could be used to investigate which .bit domains were accessed in ncp11), so it should come with a warning.

We should add ppc64 builds.

We should test on macOS.

A lot of functions that exist in pkcs11mod are unimplemented in p11mod. The easy way to find them is by grepping p11mod.go for CKR_FUNCTION_NOT_SUPPORTED. It would be desirable to implement them.

Note that some of those functions may be impossible to implement due to limitations of the p11 API. There are plenty that will work fine though, so if you see one that looks problematic, pick another one -- lots of low-hanging fruit.

We currently test Chromium with pkcs11proxy, but not p11proxy. We should add tests for p11proxy with Chromium.

In https://github.com/namecoin/nctls.so/blob/936f6f9fe41d41e96b4552bdac65417413bde32f/types.go#L18 , we cast an error to a pkcs11.Error without checking whether this cast is possible. This works fine if the backend is a pkcs11.Ctx, but it introduces the potential for problems if a generic backend is used that returns generic errors. Might be a good idea to check for that case and return a generic C.CK_RV error code.

According to Dependencies, Tor Browser's nssckbi.dll only exports C_GetFunctionList, while we're exporting a bunch of Go_ functions as well. Do we actually need to export those? Can we stop doing so without breaking anything?

We should be able to use the screenshot trick like we did for Firefox.

Probably easiest to do in a macOS VM.

miekg/pkcs11 includes a high-level API under the p11 subpackage. It would be interesting to produce a PKCS#11 module using pkcs11mod that proxies the commands to a package that exposes the p11 API. So the end-to-end testing would look like:

(PKCS#11 test app in C) --> (C ABI PKCS#11 commands) --> (pkcs11mod) --> (p11mod) --> (p11) --> (pkcs11) --> (C ABI PKCS#11 commands) --> (PKCS#11 module in C)

The main benefit here is that the p11 API is much more user-friendly to implement modules with than the pkcs11 API, which makes it easier to audit the modules.

We should test on Windows.

pkcs11-tool is the OpenSC equivalent of NSS's certutil and GnuTLS's p11tool. We should add tests for it, by having it open modules via pkcs11proxy and p11proxy and making sure the behavior doesn't change.

Currently, some Go linters are marked as non-mandatory, because we'd like to pass them but we don't right now. It would be desirable to fix whatever failures they trigger, and then enable them as mandatory.

Base Browser is a browser maintained by the Tor Browser Team; it's basically Tor Browser without Tor. Similar in concept to Kicksecure's SecBrowser. We should add tests for Base Browser.

We should add some tests that use certutil to dump certs and trust objects from CKBI. Probably the tlsrestrictnss code is a good guide for what commands to run.

The license is specified in the readme, but not in a dedicated file, which makes it hard for bots to determine the license. We should fix that.

Upstream miekg/pkcs11 added them in miekg/pkcs11#96

If pkcs11proxy is built with a target module path that doesn't exist, it will cause a Go panic:

pkcs11proxy changed line:

backend := pkcs11.New("/usr/lib64/pkcs11/p11-kit-trustX.so") // This path does not exist

Result:

$ /usr/lib64/nss/unsupported-tools/tstclnt -R ./libmypkcs11module.so  -D -h www.namecoin.org

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7fffbc461d68]

goroutine 17 [running, locked to thread]:
github.com/miekg/pkcs11.(*Ctx).Initialize.func1(0x0, 0x7fffbc3c191c)
	/home/user/go/pkg/mod/github.com/miekg/[email protected]/pkcs11.go:805 +0x38
github.com/miekg/pkcs11.(*Ctx).Initialize(0x0, 0x1, 0x7fffbc540001)
	/home/user/go/pkg/mod/github.com/miekg/[email protected]/pkcs11.go:805 +0x40
github.com/namecoin/pkcs11mod.Go_Initialize(...)
	/home/user/Downloads/pkcs11mod/pkcs11mod.go:68
Aborted (core dumped)

Obviously a nil backend isn't expected to do anything useful, but pkcs11mod should handle this more gracefully than panicking; the application may be able to cope with an erroring PKCS#11 module as long as the module doesn't panic.

osclientcerts is the Firefox PKCS#11 module that reflects client certificates from the Windows and macOS OS-wide cert store. We should add tests for it, by putting it behind pkcs11proxy and p11proxy and making sure the behavior doesn't change.

We should add gccgo builds. AFAIK gccgo handles cgo somewhat differently from Google's compiler, so this might require refactoring the build scripts.

Currently, naming of Cirrus tasks doesn't follow a clear convention, which makes sorting difficult. We should rename them with common prefixes like Lint, Test, and Compile.

Currently, CloseAllSessions is unimplemented. NSS's modutil and certutil seem to call it, so it's somewhat relevant to Namecoin, although nothing obviously bad seems to happen when it's unimplemented.

miekg/pkcs11 sets -DPACKED_STRUCTURES in the CFLAGS on Windows. We do that for main.go but not pkcs11_exported.c, which I suspect will cause issues on Windows. Maybe look into enabling that for pkcs11_exported.c on Windows?

The browser tests (Chromium/Firefox) seem to be very sensitive to network issues, and will often report a connection failure; this causes spurious Cirrus failures for us. It would be desirable to retry those tests a few times if a connection failure happens. Preferably do not retry if a certificate error is reported (not sure how easy it is to disambiguate the two).

Upstream Firefox binaries may have different behavior than GNU/Linux distro-provided packages.

GNOME Web uses GnuTLS, so we should be able to test it. Not sure if headless operation will be a problem though.

There's some C code embedded in Go code here; it looks like csbuild skips this because the resulting GCC calls are for files in a temporary directory instead of this repo's directory. We should find a way to get csbuild to lint this.