Bring the node-addon-landlock-run tree (tag v0.0.1, commit 614f7fd) into native/landlock-run as its source of record: launcher development happens here, next to the harness consumers, and the standalone repository becomes the release mirror the tree is exported to for packing and publishing (procedure in native/README.md). The subtree keeps its own pnpm workspace and lockfile and is NOT added to the harness workspace: harness installs, gates, and CI never touch it. The mirror's .github/ stays out of the subtree; a separate manually-dispatched workflow (.github/workflows/landlock-run.yml) runs the subtree's CI legs — the per-architecture native builds, real-kernel launcher proofs, and pack rehearsal — adapted with working-directory/cache paths. eslint ignores the subtree like vendor/; AGENTS.md gains the native/ layout line (+5 words on its budget ceiling).
1.5 KiB
1.5 KiB
Support matrix
Supported
| Platform package | GitHub runner (builder of record) | Notes |
|---|---|---|
node-addon-landlock-run-linux-x64 |
ubuntu-24.04 |
static musl — glibc and musl distros alike |
node-addon-landlock-run-linux-arm64 |
ubuntu-24.04-arm |
static musl — glibc and musl distros alike |
Enforcement additionally requires a kernel with Landlock enabled (5.13+). The negotiated ABI level decides the probe verdict: every access this build knows governed → full; an older ABI governing a subset → partial (still confined for everything it supports); Landlock absent or disabled → unusable, and the launcher refuses to run commands at all. The probe — not the kernel version — is the authority: a kernel built without Landlock, or with the LSM disabled, probes unusable regardless of its version.
Deliberately unsupported
- darwin: macOS consumers typically confine through
sandbox-exec/Seatbelt, which ships with the OS — there is no binary to distribute. - win32: a Windows confinement launcher would be a different mechanism in its own repository, not a port of this one.
- Other Linux architectures (riscv64, s390x, …): no native CI builder of record yet. The no-cross-toolchain rule means a platform package is added only together with a native runner that builds and proves it.
A consumer on an unsupported platform resolves a nonexistent launcher path, probes unusable, and falls closed — the documented degradation, exercised by CI's darwin leg.