fix(ansible): document the attestation verify command correctly - #127
Merged
Conversation
The comment added in #125 told consumers to run gh attestation verify <file> --repo <owner>/<repo> which fails. The signing identity in the certificate is this reusable workflow, which lives in a different repository from the artifact, so gh looks for a signer in the artifact's own repo, finds none, and reports Error: verifying with issuer "sigstore.dev" That reads like a bad artifact rather than a bad command - a consumer following the documented steps would reasonably conclude the release was not trustworthy. Verified against the published sthings-baseos-26.729.1165.tar.gz: with --signer-repo the bundle resolves to slsa provenance v1, subject digest b3a61def..., source commit eb52831, runner github-hosted. Also put the command in the release notes. The workflow comment is not where anyone looks when checking a download. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FDecVMyhtUtixsLmT4oLwY
patrick-hermann-sva
temporarily deployed
to
linting
July 29, 2026 12:35 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
patrick-hermann-sva
added a commit
that referenced
this pull request
Jul 29, 2026
…#129) The pin still referenced 1814f1e, which predates #127 and #128. Left alone the release path would keep calling the old workflow, so the corrected attestation verify command would never reach the release notes. Claude-Session: https://claude.ai/code/session_01FDecVMyhtUtixsLmT4oLwY Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
Found while verifying the first real release,
sthings-baseos-26.729.1165.The documented command does not work
#125 added this comment:
Running it against the published artifact:
The signing identity in the certificate is this reusable workflow, which lives in a different repository from the artifact. Without
--signer-repo,ghlooks for a signer in the artifact's own repo, finds none, and emits that bare error — which reads like a bad artifact rather than a bad command. A consumer following the documented steps would reasonably conclude the release was not trustworthy.The working command:
The attestation itself is fine
Verified against the published artifact:
sha256sum -con the published.sha256also passes.Also in the release notes
A workflow comment is not where anyone looks when checking a download, so the command now goes into the release body next to the digest.
Note the notes string uses
verify with --rather thanverify:. A': 'inside that unquoted YAML scalar is a mapping indicator and breaks the file — caught bycheck-jsonschemabefore pushing.🤖 Generated with Claude Code
https://claude.ai/code/session_01FDecVMyhtUtixsLmT4oLwY