Supply-chain verification

Publishing happens only through npm Trusted Publishing (OIDC) from the committed publish workflow, triggered by a version tag. There is no npm token anywhere, not in CI secrets, not on a maintainer laptop, so there is no token to steal. npm generates a SLSA v1 provenance attestation for every publish, binding the tarball to the exact repo, commit, and workflow run that produced it.

Verify it yourself, in a project that has orionfold-relay installed: run npm audit signatures and look for verified registry signatures or attestations. Or inspect the attestation directly with npm view orionfold-relay dist.attestations, no install needed. The npm package page also renders the green "Built and signed on GitHub Actions" provenance badge with a link to the workflow run.

Every release from version 0.20.0 onward attaches a CycloneDX SBOM of the production dependency tree (dev dependencies omitted) as a GitHub Release asset. It is generated by npm sbom inside the publish workflow, from the same committed lockfile the published package was built and tested against, so what the SBOM says is what the install resolves. Feed it to your scanner of choice (Dependency-Track, Grype, osv-scanner).

The npm package is deliberately small: a size guard in the publish workflow fails the release if it exceeds 10 MB. On first launch of a version, the CLI downloads the prebuilt server build for that exact version from the GitHub Release and verifies it against its sha256 sidecar before extracting. A mismatch aborts loudly. Verified downloads are cached per version. For air-gapped installs, a build-artifact URL setting accepts a file:// or mirror URL to an artifact you fetched out of band, and the sha256 sidecar is still required next to it and still verified.

Nothing in Relay self-updates. To stay on an evaluated version, install or run that exact version (for example [email protected]). Two properties make the pin meaningful.

• The version you pin is the version that runs. The build artifact is fetched by exact version and checksum-verified. There is no latest channel, no auto-upgrade, no update check.
• The stack under it is pinned too. The framework is pinned to an exact version in package.json, not a range, and releases are built and smoke-tested from the committed lockfile.

Upgrades are always an explicit act on your side: install the new version, and re-verify provenance and SBOM if your process requires it.

The publish workflow refuses to release unless, in order: the tag matches package.json; the CLI builds; the licensing test suite passes; the tarball size guard passes; the production build compiles; and a full customer simulation succeeds, which packs the tarball, installs it into a clean directory, runs the first-launch artifact download, serves the app, and exercises the free-to-licensed journey against a real signed license. A failure at any step means no publish.