openregs pull

Vendor a release from a registry, verifying it before it is unpacked.

Copy a named release out of a registry into a local directory, and verify the whole chain — signatures, the trust anchor, digests, provenance and transparency-log inclusion — over the copied bytes BEFORE any of them reach the target path. A release that fails any check is not unpacked: the staging directory is removed and the target is left exactly as it was. Nothing is ever extracted, because a registry holds a release as a file tree and the file list comes from the release’s own signature manifest, not from a listing the registry composes. Those checks say the bytes are a genuine release and not that they are the release asked for, so the pin is checked too: a registry serving a release under a name that is not its own is refused before anything is staged, and --expect refuses anything but one exact release by digest. A registry reached over https runs exactly the same checks in exactly the same order as one on disk. Pulling the same release twice reads one file, re-checks what is already on disk and writes nothing.

openregs pull [-h] --from <registry> [--into <path>] [--expect <sha256>] [--force]
                     [--key <cosign.pub>] [--log-key <log.pub>] [--trust <path>] [--root <path>]
                     <regime>@<tag>

Argument
<regime>@<tag>	the release to vendor, for example fixreg@2025.04 (required)

Option
--from <registry>	the registry to pull from. A directory (or file:// URL) laid out as <registry>/<regime>/<tag>/, or a published registry over https: point it at the GitHub repository that owns the regime (https://github.com/<owner>/<repo>) and the release is read from that repository’s release assets. Plain http is accepted only to loopback. There is no default: releases live in the repository that owns their regime, so there is no one endpoint to invent, and a pull that guessed at a source would be exactly the wrong thing for this command to do (required)
--into <path>	the directory to vendor into; the release lands at <path>/<regime>/<tag>/. Defaults to the current directory
--expect <sha256>	the release to accept, by digest rather than by name: the sha256 of its release-meta.yaml, which is the value an answer carries as corpus.release_meta_sha256 and which every pull prints. A tag is a name and can be rebuilt or moved wherever a mirror’s operator decides what it points at; this is the release. Anything else is refused before a byte is staged
--force	replace an already-vendored copy instead of refusing to touch it
--key <cosign.pub>	a signing key to accept, repeatable. Given, it replaces the roster: the release’s own copy of its public key is never an anchor. Default: config/trust.yaml (repeatable)
--log-key <log.pub>	a transparency-log key to accept, repeatable (repeatable)
--trust <path>	read the trust roster here instead of config/trust.yaml
--root <path>	repository root, where the trust roster and the regime names are read from