Summary
checklevelprov accepts --expected-issuer / --expected-san, and sourcetool verify honours them (our attestations, signed under our own workflow identity, verify SUCCESS with those flags). But the attest-time chain evaluation does not: Backend.GetBranchControlsAtCommit constructs its attester with attest.GetDefaultVerifier(), which pins the default slsa-framework/source-actions@refs/heads/main identity. Result: prior attestations signed by any other identity are treated as absent ("No provenance attestation found on "), the SLSA_SOURCE_SCS_PROVENANCE/SLSA_SOURCE_SCS_VSA control clocks never carry over from the chain, ComputeEligibleSince never finds an eligible start, and the emitted VSA is stuck at SLSA_SOURCE_LEVEL_1 forever — even with every control enforced and a continuous chain of prior attestations in the notes.
This affects anyone running the CLI inside their own workflow rather than the slsa-framework reusable workflow — which the design otherwise supports and which is necessary for orgs that want their own signing identity on their own source claims.
Repro
- Run
checklevelprov ... --push=note in your own repo's workflow (own OIDC identity), twice (two commits).
- Second run, with
--expected-issuer/--expected-san pointing at your workflow: logs "No provenance attestation found" for the prior commit despite the signed note existing and sourcetool verify succeeding on it with the same flags.
Suggested fix
Thread the configured expected identity (sourcetool.WithExpectedIdentity) through to the attester/verifier used inside the backend (attest.NewAttester(... attest.WithVerifier(...))) instead of GetDefaultVerifier(). Related context: with #433/#434 patched, everything else in the pipeline works for us — this is the last blocker to correct level computation for external identities.
Summary
checklevelprovaccepts--expected-issuer/--expected-san, andsourcetool verifyhonours them (our attestations, signed under our own workflow identity, verify SUCCESS with those flags). But the attest-time chain evaluation does not:Backend.GetBranchControlsAtCommitconstructs its attester withattest.GetDefaultVerifier(), which pins the defaultslsa-framework/source-actions@refs/heads/mainidentity. Result: prior attestations signed by any other identity are treated as absent ("No provenance attestation found on "), theSLSA_SOURCE_SCS_PROVENANCE/SLSA_SOURCE_SCS_VSAcontrol clocks never carry over from the chain,ComputeEligibleSincenever finds an eligible start, and the emitted VSA is stuck atSLSA_SOURCE_LEVEL_1forever — even with every control enforced and a continuous chain of prior attestations in the notes.This affects anyone running the CLI inside their own workflow rather than the slsa-framework reusable workflow — which the design otherwise supports and which is necessary for orgs that want their own signing identity on their own source claims.
Repro
checklevelprov ... --push=notein your own repo's workflow (own OIDC identity), twice (two commits).--expected-issuer/--expected-sanpointing at your workflow: logs "No provenance attestation found" for the prior commit despite the signed note existing andsourcetool verifysucceeding on it with the same flags.Suggested fix
Thread the configured expected identity (
sourcetool.WithExpectedIdentity) through to the attester/verifier used inside the backend (attest.NewAttester(... attest.WithVerifier(...))) instead ofGetDefaultVerifier(). Related context: with #433/#434 patched, everything else in the pipeline works for us — this is the last blocker to correct level computation for external identities.