Bug Description
aicr verify reports "Trust level: verified" for a bundle made with
--attest alone, but "Trust level: attested" for the same recipe
with --attest --data ./extdata (one extra registry.yaml covered
transitively via checksums.txt). Same identity, same Sigstore checks
all green (4/4), same envelope shape — yet the tier differs and no
line of output explains why.
Impact
Medium — confusing UX, undermines confidence in the attestation model.
Not destructive.
Component
Bundlers / verifier
Regression?
Unknown.
Reproduction
Requires a browser (run on laptop):
mkdir -p /tmp/attest-tier && cd /tmp/attest-tier
aicr recipe --service eks --accelerator h100 --intent training \
--os ubuntu --platform kubeflow -o recipe.yaml
# Bundle 1: attest only
aicr bundle -r recipe.yaml -o ./b1 --deployer argocd-helm \
--repo https://github.com/example/m --attest
aicr verify ./b1 # → Trust level: verified
# Bundle 2: attest + data
mkdir extdata
curl -sSL https://raw.githubusercontent.com/NVIDIA/aicr/v0.12.0-rc1/recipes/registry.yaml \
-o extdata/registry.yaml
aicr bundle -r recipe.yaml -o ./b2 --deployer argocd-helm \
--repo https://github.com/example/m --data ./extdata --attest
aicr verify ./b2 # → Trust level: attested
Where
pkg/bundler/verifier/trust.go (around line 141, "Trust level check")
— wherever the trust-tier calculation decides between verified and
attested based on what's covered by the attestation envelope.
Proposed Fix
Pick one — current state is the worst of both: behavior differs but the
user has no signal why.
A. Remove the tier delta when the attestation fully covers --data
files (it does, transitively via the checksums.txt subject). Makes
the two cases equivalent.
B. Keep the delta but emit a one-line rationale in aicr verify
output explaining which input caused the drop:
Trust level: attested
↳ external --data files included; verified tier requires bundle
to use only embedded recipe data
Scope
Confirm with the bundler author whether the tier delta is intentional.
If so, fix is small: thread a reason string through the trust-level
calculation and print it. If not, fix is even smaller: equalize the tier
when transitive coverage holds.
Stable-blocking: probably not, but it is the kind of UX nit users
will keep tripping on.
Bug Description
aicr verifyreports "Trust level: verified" for a bundle made with--attestalone, but "Trust level: attested" for the same recipewith
--attest --data ./extdata(one extraregistry.yamlcoveredtransitively via
checksums.txt). Same identity, same Sigstore checksall green (4/4), same envelope shape — yet the tier differs and no
line of output explains why.
Impact
Medium — confusing UX, undermines confidence in the attestation model.
Not destructive.
Component
Bundlers / verifier
Regression?
Unknown.
Reproduction
Requires a browser (run on laptop):
Where
pkg/bundler/verifier/trust.go(around line 141, "Trust level check")— wherever the trust-tier calculation decides between
verifiedandattestedbased on what's covered by the attestation envelope.Proposed Fix
Pick one — current state is the worst of both: behavior differs but the
user has no signal why.
A. Remove the tier delta when the attestation fully covers
--datafiles (it does, transitively via the
checksums.txtsubject). Makesthe two cases equivalent.
B. Keep the delta but emit a one-line rationale in
aicr verifyoutput explaining which input caused the drop:
Scope
Confirm with the bundler author whether the tier delta is intentional.
If so, fix is small: thread a reason string through the trust-level
calculation and print it. If not, fix is even smaller: equalize the tier
when transitive coverage holds.
Stable-blocking: probably not, but it is the kind of UX nit users
will keep tripping on.