Check a claim yourself · ConfigHub Workshop

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

1. Check one claim yourself

Choose the result you want to check, then run the matching command. These commands test this project's published results; they do not install your application.

A claim is checked only when the named command or receipt covers it. Everything else is not checked, even when a nearby test passed. First decide which answer you need. What you have, what it will produce, whether the destination can accept it, and whether it actually worked each need different inputs. Passing one check does not mean the next one passes.

Question	Minimum input	Deployment needed?
What do I have?	The source, package, snapshot, or files to inspect.	No
What will it produce?	Source inputs plus its native tool, or literal objects where this step is a no-op.	No
Can this destination accept it?	The exact candidate plus current destination facts.	No
Did it work?	The exact delivered revision plus the live evidence required by the claim.	Yes

Then use the smallest check that answers it. Some checks read evidence already committed to the repository. Others create clusters and produce a new live result. The table tells you which kind you are about to run.

Question	Command or page	Needs cluster?	What it proves
What known configuration risks appear in these rendered objects?	`cub plugin install confighub/homebrew-tap@cub-scan-v0.7.3 --name scan` `cub check --format json --output cub-check.json ./rendered`	No	A local advisory result with stable finding IDs and the pinned pattern bundle. It is not a cluster or runtime test.
Is this cub-scout receipt intact?	`cub-scout receipt validate <receipt.json>`	No	The receipt's fingerprint and structure validate locally.

Product commands

cub, helm, kubectl, Argo, and Flux render, install, deliver, or manage configuration.

Project checks

The npm run ... commands that check this repository's generated files, receipts, and live lanes live in Verification, not on this page. npm run verify runs the whole chain.

Saved or fresh evidence

Saved evidence is already in the repository. Fresh evidence comes from a new run that may create kind clusters, use ConfigHub, publish OCI artifacts, and write receipts. Run live checks one at a time.

Open detailed instructions

Topic	Use it for
Verification docs	The canonical docs landing page for proof commands and render-record-route.
Verify It Yourself	The practical command list for offline checks, rendered installs, parity receipts, and cub-scout receipts.
Verification Lanes	What each type of test proves and what it does not prove.
Choosing Commands	When to use product commands versus repo verifiers.
Expected Results And Clusters	Which steps need a cluster and what output to expect.
Outcomes And Tests	Which repo promises map to which test commands and CSVs.
Live Parity	How to read live Helm-vs-ConfigHub parity status.
Chain Of Proof	Which boundary is proven by render, ConfigHub, delivery, and live observations.
What We Refuse To Claim	The refusal boundaries that keep proof language honest.
Two-Cluster Harness	The stricter Helm-vs-cub kind harness.
NPM Script Catalog	The full script catalog for maintainers.

2. Verify an entry yourself

The catalog reports what a configuration does rather than certifying it as secure for your cluster. It gives you the exact objects, their source, and the checks recorded against them. Verify a signed package yourself with the immutable reference and the two annotations from its catalog record.

cosign verify \
  --certificate-identity helm-expt-package-signer@nth-fort-499605-q5.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com \
  --annotations confighub.com/package-path=packages/bitnami/redis/25.5.3 \
  --annotations confighub.com/package-sha256=<package-sha256> \
  europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:25.5.3@sha256:<manifest-digest>

Each chart-version page fills in the recorded digests. Some evidence is partial by design. A digest proves integrity inside a known trust chain and says nothing outside one. A scan finding still needs a human decision. A clean render tells you the objects are well formed, while cloud identity, storage, and runtime policy at the target remain unchecked.

Behind every claim is a count you can read and a command you can rerun. Read the current counts, see what each test covers, and check one claim yourself.

What stays available

The catalog retains 180 exact package versions across 124 components. 180 have a dated registry receipt; the oldest current receipt is from 2026-08-26. A new review adds a version. It does not silently replace an older package.

We have caught 2 cases where an upstream publisher changed the bytes behind an existing version string. The catalog keeps the reviewed bytes and records both digests so you can see the change. Read those cases.

A chart is listed only after its license evidence is recorded. Normal refreshes are additive. If a legal or factual correction is required, the change must be named rather than hidden. Read the retention policy.

What this catalog does not claim

The catalog proves the named configurations it lists. It does not prove every possible values file, and it does not certify a chart as secure for your cluster. Your own values still need to be rendered and checked, which is what Is my configuration right? is for.

A green result on one test does not mean the next test passes. A signature proves origin and integrity, not safety, so scans, policies, and live evidence carry the safety claims. A row marked watch, blocked, or refused stays that way until a receipt changes it. Read what is not ready yet, or what this project refuses to claim.

3. Choose the right verify command

Four commands check different OCI shapes, and none of them substitutes for another.

Have an installer-package ref? Run cub installer inspect <ref> --json first, to confirm the manifest and layer digests the publication receipt recorded.
Then run cosign verify with the identity, issuer, and annotations from the chart page, to confirm the named service account signed that exact digest.
Have a certified-bundle ref? Run cub config verify oci://…@sha256:…. It pulls the bundle, finds its receipt, and re-hashes every listed file; it checks a signature only where one is attached.
Have the downloadable package index? Run cosign verify-blob --bundle packages.sigstore.json … against the committed index signature.

These four commands cover the shapes listed above them. A release, a stack index, a stack release, and a runtime image have no matching command here, because these docs describe no signing for those shapes.