attest-boot: state the verification predicate, and stop advertising the weak one - #165
Merged
Merged
Conversation
…he weak one attest-boot.yml has signed the bootstrap chain since 2026-08-10, but nothing states what a verifier must check. An attestation with no predicate behind it is decoration: `--owner` accepts any workflow in any repo under the org, and `--repo` accepts any workflow in this one — neither is the claim the chain needs, and the run summary was advertising the second. docs/boot-attestation-policy.md writes the predicate literally — subject digest, predicate type, source repo, signer workflow, source ref, OIDC issuer — plus what happens on failure at each enforcement point. Two decisions worth naming: - Enforcement belongs at the PIN/SUM_* bump, not at boot. The bump is when a digest BECOMES trusted, and it happens in CI, online, with a trust root already present. Verifying at boot would need network plus a pinned Sigstore bundle in the verifying image, which then needs its own provenance story; moving the gate to CI terminates that regress at a boundary already gated. Boot keeps relying on the digest chain, which already fails closed offline. - Ref pinning is left Aspirational on purpose. --signer-workflow constrains repo and workflow path but not ref; the ref belongs in --cert-identity, and the accepted form has NOT been checked against the gh version this org ships. Recording that as unverified rather than asserting it. The run summary now emits the full predicate and says plainly that --owner and --repo alone are not the policy. No gate evaluates the predicate yet — the doc grades itself Aspirational and names the check as the next step. The predicate had to exist first. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ELNyzpaVesKrUPkUpDjCXw
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
attest-boot.yml has signed the bootstrap chain since 2026-08-10, but nothing
states what a verifier must check. An attestation with no predicate behind it
is decoration:
--owneraccepts any workflow in any repo under the org, and--repoaccepts any workflow in this one — neither is the claim the chainneeds, and the run summary was advertising the second.
docs/boot-attestation-policy.md writes the predicate literally — subject
digest, predicate type, source repo, signer workflow, source ref, OIDC issuer
— plus what happens on failure at each enforcement point. Two decisions worth
naming:
digest BECOMES trusted, and it happens in CI, online, with a trust root
already present. Verifying at boot would need network plus a pinned Sigstore
bundle in the verifying image, which then needs its own provenance story;
moving the gate to CI terminates that regress at a boundary already gated.
Boot keeps relying on the digest chain, which already fails closed offline.
repo and workflow path but not ref; the ref belongs in --cert-identity, and
the accepted form has NOT been checked against the gh version this org
ships. Recording that as unverified rather than asserting it.
The run summary now emits the full predicate and says plainly that --owner and
--repo alone are not the policy.
No gate evaluates the predicate yet — the doc grades itself Aspirational and
names the check as the next step. The predicate had to exist first.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01ELNyzpaVesKrUPkUpDjCXw