openregs release

Build a dated content release from the canon at one commit.

Compile a regime’s canon into the artifacts a consumer actually uses: a SQLite bundle, a graph index, a chunk-and-embedding table, generated constants and a diff manifest, plus release-meta.yaml carrying the commit, the spec schema range, the build timestamp and every artifact’s digest. A release is a function of a commit and of nothing else: the working tree is never read and the wall clock is never consulted, so rebuilding a tag from the same sha reproduces the same bytes.

openregs release [-h] <command> ...

openregs release build

Build <regime>@<tag> into regimes/<regime>/releases/<tag>/.

Build one release. --tag is <YYYY.MM> and fixes the date the release speaks for (2025.04 is read as of 2025-04-01); the bundle still carries every unit version with its window, so the release answers as-of questions across its whole range. The diff manifest is computed against the greatest already-built tag before this one, read from that release’s own corpus.sqlite on disk — a release built at a commit cannot be inside it.

openregs release build [-h] [--regime <name>] --tag <YYYY.MM> [--commit <rev>]
                              [--out <path>] [--root <path>] [--embeddings-config <path>]

Option
--regime <name>	—
--tag <YYYY.MM>	(required)
--commit <rev>	the revision to compile; any git revision, default HEAD (default HEAD)
--out <path>	write the release here instead of regimes/<regime>/releases/<tag>/
--root <path>	repository root
--embeddings-config <path>	read the embedding model configuration here instead of config/embeddings.yaml; the model is resolved before anything is read, and an unregistered name fails there

openregs release verify

Recompute a built release’s digests and compare them with release-meta.yaml.

Read release-meta.yaml and recompute the sha256 of every artifact it declares. A file’s digest is the digest of its bytes; the constants-src directory’s is the digest of its listing, the recipe being stated in the manifest’s own header.

openregs release verify [-h] <release-dir>

Argument
<release-dir>	(required)

openregs release keygen

Write a fresh P-256 release signing key pair.

Generate cosign.key and cosign.pub in a directory. The private half is the one file in this system that must never be committed — .gitignore refuses it — and the public half belongs in config/trust.yaml, where a reviewer approves it.

openregs release keygen [-h] --out <path> [--force]

Option
--out <path>	directory to write the pair into (required)
--force	overwrite an existing key pair

openregs release sign

Sign a built release, attest its provenance and log it.

Sign every artifact of a built release with cosign’s key-based sign-blob format, write a SLSA provenance statement linking the tag to the commit, the CI run and every snapshot sha256 in SOURCES.lock, and append one transparency-log entry per signature. The signed head of the log and each entry’s inclusion proof are bundled into the release, which is what lets openregs verify --release prove inclusion offline. Digests are recomputed first: a release that already disagrees with its own manifest is refused rather than signed.

openregs release sign [-h] [--key <cosign.key>] [--fixture-key]
                             [--signer {auto,cosign,local}] [--run-id <id>] [--log <path>]
                             [--log-key <path>] [--log-origin <name>] [--root <path>]
                             <release-dir>

Argument
<release-dir>	(required)

Option
--key <cosign.key>	the PEM private key to sign with (openregs release keygen writes one)
--fixture-key	sign with the published, non-secret fixture key — reproducible everywhere and trusted by nobody. For this repository’s own releases and for tests
--signer <value>	how to produce the signature: the cosign binary as a subprocess, the in-process P-256 signer, or auto (cosign when it is installed). The artifact is identical (one of auto, cosign, local, default auto)
--run-id <id>	the CI run this release is attributed to; defaults to $GITHUB_RUN_ID
--log <path>	the transparency log directory; default <root>/state/translog
--log-key <path>	the PEM key the log signs its checkpoints with; default the fixture log key
--log-origin <name>	the log’s origin line in its checkpoints; default openregs.io/<regime>
--root <path>	repository root

openregs release publish

Package a signed release for PyPI and npm, and publish it to a registry.

Turn a signed release into the two packages a dependency manager installs — openregs-data-<regime> for pip and @openregs/data-<regime> for npm — each wrapping corpus.sqlite, release-meta.yaml verbatim and the whole attestation/ directory, so the signature travels with the data and a consumer can check the bytes the registry served them. Both packages are written into a registry laid out on the filesystem: a PEP 503 simple index pip installs from with --index-url file://…, and an npm registry directory a local server answers packument requests from. --mode dry-run stops there; --mode live additionally uploads, and refuses with a non-zero exit if a credential is missing rather than skipping the upload. The release’s five verification checks run before a byte of it is read, and every package is a function of the release alone: member timestamps come from its built_at, so publishing one release twice produces identical archives.

openregs release publish [-h] --release <regime>@<tag> [--path <release-dir>]
                                [--mode <mode>] --out <dir> [--pypi <dir>] [--npm <dir>]
                                [--pypi-url <url>] [--npm-url <url>] [--key <public-key>]
                                [--log-key <public-key>] [--trust <path>] [--root <path>]

Option
--release <regime>@<tag>	the built and signed release to publish, for example fixreg@2025.04 (required)
--path <release-dir>	publish the release in this directory instead of resolving --release in the checkout
--mode <mode>	dry-run or live; dry-run writes the local registries and uploads nothing (one of dry-run, live, default dry-run)
--out <dir>	where the packages, the local registries and publish-report.json are written; created if absent (required)
--pypi <dir>	the local PyPI registry to publish into (default: <out>/registries/pypi)
--npm <dir>	the local npm registry to publish into (default: <out>/registries/npm)
--pypi-url <url>	the index a --mode live upload targets (default: the public PyPI upload endpoint)
--npm-url <url>	the registry a --mode live upload targets (default: the public npm registry)
--key <public-key>	accept this signing key as a trust anchor instead of config/trust.yaml (repeatable)
--log-key <public-key>	accept this transparency-log key as a trust anchor (repeatable)
--trust <path>	read the trust roster from here instead of config/trust.yaml
--root <path>	repository root, where the release and the trust roster are read from

openregs release assets

Lay a verified release out as the flat asset tree a registry serves.

Write a release into <out>/<regime>@<tag>/ with every file’s path flattened into one asset name — attestation/sigs/corpus.sqlite.sig becomes attestation__sigs__corpus.sqlite.sig — which is the layout openregs pull --from <url> reads and the layout a GitHub release’s assets have to be uploaded under, because an asset’s name is a basename and a release is a tree. Serve the parent directory over https, or upload the contents to a GitHub release, and the result is a registry. The release’s five verification checks run before a byte of it is copied: a mirror is as wide a distribution as a package, and bytes that do not verify here fail for every consumer who later fetches them, with nothing pointing back here. Nothing is uploaded and no credential is read.

openregs release assets [-h] --release <regime>@<tag> [--path <release-dir>] --out <dir>
                               [--key <public-key>] [--log-key <public-key>] [--trust <path>]
                               [--root <path>]

Option
--release <regime>@<tag>	the built and signed release to lay out, for example fixreg@2025.04 (required)
--path <release-dir>	lay out the release in this directory instead of resolving --release in the checkout
--out <dir>	the registry root to write into; the assets land in <dir>/<regime>@<tag>/ and <dir> is what --from names. Created if absent (required)
--key <public-key>	accept this signing key as a trust anchor instead of config/trust.yaml (repeatable)
--log-key <public-key>	accept this transparency-log key as a trust anchor (repeatable)
--trust <path>	read the trust roster from here instead of config/trust.yaml
--root <path>	repository root, where the release and the trust roster are read from