Summary
Extend AICRConfig (--config) to cover aicr verify. Today the schema is scoped to the producer pipeline — pkg/config/doc.go states the config is accepted "on the snapshot, recipe, bundle, and validate commands." verify is the consumer/verifier side and has no --config support, so verification policy can't be captured in the same version-controlled document as the rest of an end-to-end workflow.
Motivation
A --config-driven workflow can build and validate reproducibly, but the verification gate (trust floor, pinned creator, CLI-version constraint, private trust root, KMS key) still has to be passed as flags every time. A spec.verify section would let teams commit their verification policy alongside the recipe/bundle/validate config — useful for both end users and for testing the supply-chain surface.
Proposed change (for discussion)
Add an optional spec.verify section mapping the aicr verify flags that are durable (non-secret) inputs:
minTrustLevel (--min-trust-level)requireCreator (--require-creator)cliVersionConstraint (--cli-version-constraint)certificateIdentityRegexp (--certificate-identity-regexp)key (--key, a KMS URI or local PEM path)trustRoot (--trust-root, a path)
All of these are references/policy, not secrets, so none of the identity-token concerns apply. CLI flags would win over config, consistent with the existing commands.
Open question / scope
This is a scope expansion: the config was intentionally limited to the producer pipeline, and verify introduces a consumer-side actor to the schema. Filing under the epic for the team to decide whether consumer-side verification policy belongs in AICRConfig. Close as out-of-scope if the team prefers to keep the config producer-only.
Epic: #1149
Related: #1152 (verify --key), #1153 (verify --trust-root)
Summary
Extend
AICRConfig(--config) to coveraicr verify. Today the schema is scoped to the producer pipeline —pkg/config/doc.gostates the config is accepted "on the snapshot, recipe, bundle, and validate commands."verifyis the consumer/verifier side and has no--configsupport, so verification policy can't be captured in the same version-controlled document as the rest of an end-to-end workflow.Motivation
A
--config-driven workflow can build and validate reproducibly, but the verification gate (trust floor, pinned creator, CLI-version constraint, private trust root, KMS key) still has to be passed as flags every time. Aspec.verifysection would let teams commit their verification policy alongside the recipe/bundle/validate config — useful for both end users and for testing the supply-chain surface.Proposed change (for discussion)
Add an optional
spec.verifysection mapping theaicr verifyflags that are durable (non-secret) inputs:minTrustLevel(--min-trust-level)requireCreator(--require-creator)cliVersionConstraint(--cli-version-constraint)certificateIdentityRegexp(--certificate-identity-regexp)key(--key, a KMS URI or local PEM path)trustRoot(--trust-root, a path)All of these are references/policy, not secrets, so none of the identity-token concerns apply. CLI flags would win over config, consistent with the existing commands.
Open question / scope
This is a scope expansion: the config was intentionally limited to the producer pipeline, and
verifyintroduces a consumer-side actor to the schema. Filing under the epic for the team to decide whether consumer-side verification policy belongs inAICRConfig. Close as out-of-scope if the team prefers to keep the config producer-only.Epic: #1149
Related: #1152 (
verify --key), #1153 (verify --trust-root)