Browse, export, pull, and verify a release
Explore the outputs and evidence in an existing release, download a named output, and apply your consumer
policy separately. Start at the repository root with bin/nvkr built using the quickstart.
Browsing, export, and output pulling work on macOS and Linux; verification runs on Linux, directly or
through Docker on macOS.
Find an output
Set RELEASE_REF to the exact publication-root reference emitted by a completed publication:
the full registry/repository followed by @sha256: and its digest. A tag, URL, or individual output
manifest is not a release root. Obtain this reference from the release publisher. Current NVKR requires
publication-root v4; historical v3 publication roots are rejected.
The listing shows named outputs, artifact types, components, Build Digests, and evidence. Registry access
uses your existing credentials; add --anonymous to each command for a public registry.
Set OUTPUT_NAME to an exact name from that listing. Keep using the same terminal:
JSON preserves complete identifiers. Open the Mermaid export in a compatible viewer to follow output, component, and evidence relationships. This is release membership, not build ordering.
Browsing validates all release metadata before filtering, without downloading artifact payload layers, including OS disk images. It does not verify payload bytes, signatures, or your acceptance policy.
Export the complete description
This writes nvkr.dev/release-description/v1 JSON with all named outputs, platform metadata and bound
source/evidence records. The release reference supplies every input; no Plan, mapping, platform selection
or producer checkout is required. Consumers own installation roles and compatibility checks. See the
description contract for fields and inspection
limits. Export and unfiltered JSON browsing produce the same description, without verifying payloads or policy.
Download an output
Use the exact name from the listing and choose a new destination directory:
The destination contains the selected format’s files: executable bundle members, a QCOW2 disk, a Helm chart
archive, an OCI image layout, or an APT repository tree. See the output format table
for exact filenames and layout. For example, if the listing includes nvkectl-linux-arm64:
This creates ./nvkectl-linux-arm64/nvkectl with its recorded permission mode. For every format, --out is
required, must not already exist, and needs an existing parent directory. The command does not install or
execute the files, and it does not select a platform automatically. An aggregate image includes all its
declared platforms. A disk retains its plain or declared LUKS2-encrypted QCOW2 bytes; pulling does not decrypt it.
Add --anonymous for a public registry.
Pulling checks the complete release metadata and evidence, then downloads and checks only the selected output’s payloads. It does not authenticate signatures or apply your acceptance policy. Use the same exact release reference in the verification step below before treating those bytes as accepted. Malformed or unsupported format metadata fails with a coded error before payload or destination work.
Verify against an accepted policy
On Linux, use a pinned, static Linux cosign executable and independently accepted signer identity pattern and OpenID Connect issuer. Set the four variables below from your trusted tool configuration and consumer policy; do not derive accepted identities from an untrusted candidate merely to make it pass.
This scope downloads and checks artifact bytes, signatures, and production attestations under that policy.
For a faster check that skips artifact payload layers, including disk images, use the same accepted policy
with --scope authenticity:
Authenticity verifies the root and every required output’s signatures and production provenance, plus
required signed SBOMs and their metadata membership. Its result explicitly reports
payloadIntegrityVerified: false: authenticity verified; payload integrity not checked. It cannot
authorize payload export or exact-input matching. Both scopes enforce the selected disk-evidence minimum;
--minimum-disk-evidence strict requires signed inspected-disk evidence, but authenticity does not inspect
the disk itself. Neither scope provides qualification or the capability-gated full release scope.
To export the verified held closure, also supply the exact producing inputs and originating invocation. Set these paths and identities from the accepted producing Run; use a fresh directory:
The lifecycle owner requires its own exact-input receipt before export. Metadata-only
release export does not verify payloads or signer policy. See
NVKE nightly workflow
for downstream testing and its current admission limits.
From macOS, use the consumer script to run the
artifact-publication verification inside its pinned Linux Docker image. It builds a Linux amd64 nvkr
helper with the repository’s pinned Go toolchain; supply a static Linux amd64 cosign
executable and its trusted digest:
Add --anonymous for public releases. Private releases need --registry-config
pointing to a Docker auth directory with inline credentials; host credential helpers
cannot run inside that container. The script defaults to Docker on macOS and native
execution on Linux. Both require a current v4 publication and the same accepted policy.
See release navigation for local layouts and inspection details, and the verification lifecycle for policy and capability requirements.