Releases & supply chain

Paraloom releases are built and published from CI with a verifiable supply chain. Every published artifact comes with:

• A SHA-256 checksum (SHA256SUMS file)
• A CycloneDX SBOM (Software Bill of Materials)
• A Sigstore signature over the checksums file (keyless, OIDC-bound to the GitHub Actions workflow)

This closes issue #70. Implementation lives in .github/workflows/release.yml in paraloom-core.

Platforms

Each release publishes both the unified paraloom CLI and the node-only paraloom-node for the two ✓ targets. Windows / ARM Linux / Intel macOS aren't built as signed binaries yet (Solana SDK on Windows MSVC + RocksDB cross-build are post-v0.5.0 follow-ups) — build from source per Quick start, and Windows runs fine under WSL2.

Verifying a release

# 1. Download the binary, checksums file, signature, and certificate
$ curl -LO https://github.com/paraloom-labs/paraloom-core/releases/latest/download/paraloom-node-linux-amd64
$ curl -LO https://github.com/paraloom-labs/paraloom-core/releases/latest/download/SHA256SUMS
$ curl -LO https://github.com/paraloom-labs/paraloom-core/releases/latest/download/SHA256SUMS.sig
$ curl -LO https://github.com/paraloom-labs/paraloom-core/releases/latest/download/SHA256SUMS.pem

# 2. Verify the Sigstore signature on the checksums file
$ cosign verify-blob \
    --certificate SHA256SUMS.pem \
    --signature SHA256SUMS.sig \
    --certificate-identity-regexp 'https://github.com/paraloom-labs/paraloom-core/.*' \
    --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
    SHA256SUMS

# 3. Verify the binary matches the (now-trusted) checksums file
$ sha256sum -c SHA256SUMS --ignore-missing
paraloom-node-linux-amd64: OK

If any step fails, do not run the binary. Open an issue at paraloom-core/issues.

SBOM

A CycloneDX SBOM is published with each release as paraloom-core-sbom.cdx.json, with its own Sigstore signature (.sig + .pem). It enumerates every direct and transitive Cargo dependency, with version, license, and source hash. Useful for compliance scans and dependency-vulnerability tracking.

$ curl -LO https://github.com/paraloom-labs/paraloom-core/releases/latest/download/paraloom-core-sbom.cdx.json
$ jq '.components | length' paraloom-core-sbom.cdx.json
347

Container image

Releases are also published to GHCR as a container image:

$ docker pull ghcr.io/paraloom-labs/paraloom:v0.5.0-rc5

# verify image signature
$ cosign verify ghcr.io/paraloom-labs/paraloom:v0.5.0-rc5 \
    --certificate-identity-regexp 'https://github.com/paraloom-labs/paraloom-core/.*' \
    --certificate-oidc-issuer 'https://token.actions.githubusercontent.com'

Why keyless Sigstore

We don't sign with a long-lived private key — that key would be a single point of compromise. Sigstore keyless flow binds the signature to:

• The specific GitHub Actions workflow that built the artifact (release.yml)
• The specific commit SHA (recorded in the certificate)
• A short-lived OIDC token (issued by GitHub, expires within minutes)

This means a leaked CI secret or developer machine can't be used to forge a signed release. Verification checks the OIDC issuer and identity regex above.

Release cadence