Consumer guide
Verifying & trust
Every artifact is signed at publish time, and the hub verifies that signature before it will serve the artifact. The hub records the signer's identity, so verifying a release takes one command and no prior knowledge of the publisher.
Verifying a release
grcli verify checks a remote release without downloading it — and without
installing anything else; verification is built into grcli:
$grcli verify --repository finos-ccc/ccc.objstor.cn --version 1.0.0 The hub recorded the signer's identity when the release was published; grcli fetches it, checks the signature against it, and prints the identity it used — noting that the hub is its source, so that trust is visible rather than silent. The signature check itself runs against Sigstore and its Rekor transparency log, independent of the hub: the hub supplies only which identity to expect. Each release page shows the recorded identity and offers this exact command to copy.
A release published before the hub verified signatures has no recorded identity — grcli says so and points at the explicit flags below; the durable fix is for the publisher to re-publish.
What a signature proves
Signatures are attached as OCI referrers of the bundle, not baked into the bundle bytes. The hub verifies them at ingest for Gemara artifacts and evaluator plugins alike, records the canonical signer identity, and rejects an unsigned or unverifiable publish — an artifact it cannot verify is never served.
Verifying independently
A high-assurance consumer can assert the expected identity themselves and bypass the hub lookup
entirely — the check then depends on nothing the hub asserts. Pass the publisher's keyless workflow
identity (the OIDC issuer defaults to GitHub Actions; override
--certificate-oidc-issuer for other providers):
$grcli verify --repository finos-ccc/ccc.objstor.cn --version 1.0.0 --certificate-identity <workflow-url>
…or a public key with --cosign-key <key>.pub — the one verify path
that still uses a local cosign install.
The registry endpoint
The OCI registry uses bearer-token auth: an unauthenticated probe of
GET /v2/ returns 401 with a
WWW-Authenticate: Bearer realm="…/v2/token" challenge — that's the correct
unauthenticated response, and how clients discover where to mint a registry token (scoped for pull or push).
grcli handles this for you; you'd only see it probing the registry directly.
Yanking
Only a gemara-admin can yank a version — publishers (namespace members and
write:<Type> holders) can publish but cannot yank. Yanking doesn't
delete content; the manifest stays in the registry, but subsequent fetches return a "tombstoned"
response so consumers know not to rely on it.
After a release verifies, Reading & using covers the bundle's layout,
streaming with cat, rendered formats, and using verification in CI.