Tested Platforms

This page lists the operating systems, architectures, and toolchains that Craton HSM is built and tested against. It covers both the open-source Core (Apache-2.0) and the Enterprise workspace (BSL-1.1).

The Core matrix is narrower because Core ships a single PKCS#11 shared library with no hardware vendor surface. The Enterprise matrix additionally covers platform-specific backends (Windows CNG, NXP HSE, Infineon TPM) and integration targets (LDAP, OIDC, Kubernetes, KMIP). For the Enterprise workspace the authoritative document is compatibility-matrix.

Status Legend

The Enterprise project uses four status levels; the Core project uses the first three. These meanings apply throughout this site.

Rust Toolchain

MSRV is pinned in rust-version for every crate. Raising the MSRV is a breaking change for downstream consumers and requires two core-team approvals.

The Enterprise craton-hsm-awslc crate with the fips feature additionally needs Go 1.21 or newer at build time (AWS-LC's FIPS module build scripts). Go is not a runtime dependency.

Operating Systems

Linux

The x86_64-unknown-linux-musl target is exercised for Alpine and static container builds. aws-lc-rs with musl requires a C toolchain (gcc, cmake) in the build image; pure-Rust builds have no such requirement.

Windows

Windows production deployments cover the craton-hsm-cng backend. The Linux-only crates (craton-hsm-nxp, craton-hsm-infineon) are excluded on Windows and will not build with the hw feature enabled.

Building the aws-lc-rs backend on Windows requires LLVM/Clang. Set LIBCLANG_PATH to the LLVM bin directory and, if linking fails on the ASM paths, AWS_LC_SYS_NO_ASM=1. See operations/configuration.

macOS

macOS is supported for development and CI of non-FIPS builds. Do not deploy production HSM workloads on macOS. FIPS builds on macOS are not validated.

BSDs

FreeBSD, OpenBSD, and NetBSD are unsupported. The module builds have not been exercised, the mlock behaviour has not been characterised against the relevant kernels, and there is no CI coverage. Contributions that add CI coverage on a specific BSD target will be considered for Best-effort status.

CI Coverage vs. Matrix Coverage

The Enterprise CI workflow uses GitHub's ubuntu-latest, windows-latest, and macos-latest runners, each of which resolves to a single version per family at a given time (currently Ubuntu 24.04, Windows Server 2022, macOS 14). Rows marked Tested for multiple versions within a family are exercised pre-release against the listed versions but are not all covered by per-PR CI. Treat the "Tested" label on a non-latest version as equivalent to "Supported" for CI-coverage purposes until CI pins explicit versions in a future matrix expansion.

Per-Platform Feature Matrix (Core)

Container Targets

The production Dockerfile in deploy/Dockerfile uses rust:1.83-slim for the build stage and gcr.io/distroless/cc-debian12 for the runtime stage. The runtime image carries only the compiled PKCS#11 shared object and the shared libraries it links against — no shell, no package manager.

PodSecurity admission at the restricted level is required for the Kubernetes manifests shipped with the Enterprise workspace.

Running the Test Suite

PKCS#11 defines a single global state per process, so tests must run single-threaded to avoid race conditions on C_Initialize / C_Finalize:

cargo test -- --test-threads=1

For the aws-lc-rs backend:

cargo test --features awslc-backend -- --test-threads=1

CI splits the Core test suite into a parallel-safe crypto subset and a serial PKCS#11 ABI subset; see the Core ROADMAP.md for details. An evaluation of cargo-nextest (per-process test isolation) that would remove the --test-threads=1 requirement is tracked as a near-term roadmap item — see ../project/roadmap.

Known-Slow Tests (debug builds)

Use --release for faster execution of the slow paths.