docs(readme): the cosign floor was 3; a release verifies from 2.5 - #175
Merged
Conversation
The README told operators they need cosign >= 3 to verify a kaibo release. They do not, and the wrong floor turns away a working install — the failure mode is someone concluding they cannot check a signature they can in fact check. Measured against v0.3.0's real signed `checksums.txt` rather than reasoned about, because "which version can read this bundle" is not a question to answer from memory: 2.4.0 FAILS — bundle does not contain cert for verification 2.5.0 Verified OK 2.6.0 Verified OK 2.6.4 Verified OK So the floor is 2.5, and 2.4's message is quoted in the README because that is what an operator on an older cosign actually sees — it names the bundle format, not the version, so it is not self-explaining. Each "Verified OK" carries negative controls: a tampered `checksums.txt` fails the signature check and a wrong tag identity fails the SAN match, on both 2.5.0 and 2.6.4. Without those, "verified" only proves the command ran. Carried since the v0.3.0 release check on 2026-08-13, where 2.6.4 verified fine and contradicted the floor. This closes it with the floor measured rather than merely lowered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tobert
added a commit
that referenced
this pull request
Sep 3, 2026
…release page (#180) **Release-blocking.** #175 measured the cosign floor and corrected `README.md`. It corrected *only* `README.md` — I grepped one file instead of the repo, on a change whose entire subject was a claim repeated across surfaces. That is the "an idiom is never in one file" lesson, and I did not apply it. Two instances survived: - **`.github/release-body.md:36` — this becomes the GitHub release page body.** `release.yml:235` runs it through `envsubst` into `body_path`, so it is the copy every person downloading v0.4.0 reads. It would have shipped with tomorrow's tag telling them to go install cosign 3 to verify a signature that 2.5 verifies. - **`docs/releases.md:62`** — the pipeline plan, asserting the same floor as fact. Both now say **2.5**, the measured floor: 2.4.0 cannot read the bundle format; 2.5.0, 2.6.0 and 2.6.4 verify a real release, with a tampered file and a wrong tag identity both refusing. ## How it was found — and why neither half alone would have A `consult` on the release branch, run as a live end-to-end exercise of the 0.17.1 shell before tagging. It found `docs/releases.md:62` and missed the release page. The repo-wide `grep` I ran to *verify its citation* found the release page — the one that actually mattered. So the review caught what my grep in #175 missed, and my grep caught what the review missed. Worth recording as an argument for doing both rather than either. ## Also here — same family, prose the recent changes left stale `docs/sandbox-probes.md:24` promised "paths outside the mount ... resolve to nothing" in the summary at the top of the runbook. 0.17.1's walkable prefix directories made that too broad. Battery C already carves out the exception a hundred lines down, so this is the headline catching up: it now says what it means (a *file read*) and points at C. ## Not taken from the same review It also reported `CHANGELOG.md:72`'s *"kaish upgraded to 0.17.1 (from 0.14.0)"* as stale against AGENTS.md's *"from 0.14.1"*, and recommended changing the changelog. **The changelog is right.** `git show v0.3.0:Cargo.toml` pins the last release at kaish-kernel **0.14.0**, and a changelog's baseline is the last release. AGENTS.md's 0.14.1 is the pre-bump *working* pin — a different, internal baseline. Changing it would have reintroduced exactly the error #178 fixed. Verified before declining, not assumed. Docs only — no code. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
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.
The README told operators they need cosign ≥ 3 to verify a kaibo release
(
README.md:146). They do not. The wrong floor turns away a working install — thefailure mode is someone concluding they cannot check a signature they can in fact check.
Measured, not reasoned about
"Which cosign can read this bundle" is not a question to answer from memory, so I ran
each version against v0.3.0's real signed
checksums.txtand itschecksums.txt.sigstore.json:bundle does not contain cert for verification, please provide public keyVerified OKVerified OKVerified OKSo the floor is 2.5, not 3. There is a real boundary — 2.4 genuinely cannot read the
bundle format — which is why the fix lowers the floor to a measured number rather than
deleting the constraint.
2.4's message is quoted in the README because it is what an operator on an older cosign
actually sees, and it names the bundle format, not the version — so it does not explain
itself.
Negative controls
Each
Verified OKabove is backed by two controls, on both 2.5.0 and 2.6.4 — otherwise"verified" only proves the command ran:
checksums.txt→failed to verify signature: could not verify message: invalid signature when validating ASN.1 encoded signaturev9.9.9) →failed to verify certificate identity: no matching CertificateIdentity found … got "…@refs/tags/v0.3.0"Both refuse. The check is real in both directions.
Provenance
Carried since the v0.3.0 release check on 2026-08-13, where cosign 2.6.4 verified fine
and contradicted the README's floor. It sat as a known-suspect line rather than a
measured one; this closes it with a number.
Docs only — no code, no tests affected.
🤖 Generated with Claude Code