verify: the NON-CLAIMS block named releases that never shipped#10
Merged
Conversation
The paragraph that ends every verification report told the reader the three limits disqualifying this library as primary audit evidence were "fixed in v0.2", that "v0.2 closes this with the sidecar signer", and that "v0.2 adds RFC 3161 TSA timestamps". None of it shipped. README.md and ROADMAP.md have both said v0.2 closed none of them since 0.2.0; the report contradicted both. This is the worst place in the product to be wrong. NON-CLAIMS is the one paragraph an auditor reads to learn what the report does not establish, and reports are byte-deterministic precisely so they can go into an audit appendix verbatim — so the false claim travelled there under a hash that matched across reviewers. Written 2026-06-19, when v0.2 was still planned to carry the hardening. The two later passes that corrected this exact class of claim (41076ad, 44d4329) touched README.md and ROADMAP.md and missed this one, because it is a string in code rather than prose in a document. The block now states each limit as open, names no release, and points at ROADMAP.md. The guard fails on any release reference in the NON-CLAIMS section of either report: the drift is structural, since the docs are rewritten every release and this constant is not. "Keep the version numbers accurate" would fail the same way again; "name no version at all" holds. The old test asserted the block was present. It was present, and it lied.
version 0.2.0 -> 0.2.1. A patch: no change to records, signing, chaining or verification logic — only the report's NON-CLAIMS text and the test that pins it. Records written by 0.2.0 verify unchanged, and the report stays byte-deterministic.
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 paragraph that ends every verification report told the reader the three limits disqualifying this library as primary audit evidence were "fixed in v0.2", that "v0.2 closes this with the sidecar signer", and that "v0.2 adds RFC 3161 TSA timestamps". None of it shipped.
README.mdandROADMAP.mdhave both said v0.2 closed none of them since 0.2.0 — the report contradicted both, and it is live on PyPI saying so now.This is the worst place in the product to be wrong. NON-CLAIMS is the one paragraph an auditor reads to learn what the report does not establish, and reports are byte-deterministic precisely so they can go into an audit appendix verbatim. The false claim travelled there under a hash that matched across reviewers.
Written 2026-06-19, when v0.2 was still planned to carry the hardening. The two later passes that corrected this exact class of claim —
41076ad("pin claims to what ships, not to v0.2") and44d4329("the unshipped half of v0.2 is v0.3") — touchedREADME.mdandROADMAP.mdand missed this one, because it is a string in code rather than prose in a document.What changes
ROADMAP.md.tests/test_report_claims_guard.pyfails on any release reference in the NON-CLAIMS section of either report shape.Why the guard bans every version, not just the wrong ones
The drift is structural: the docs are rewritten at each release and this constant is not. "Keep the version numbers accurate" is the rule that already failed twice. "Name no version" holds — what is unproven today is unproven whichever release closes it, and where a limit is headed belongs in
ROADMAP.md, the document that actually gets updated.The previous test asserted the block was present. Presence was never the problem: it was present, and it lied.
Found by running the verifier against a fresh chain while restarting the dogfood — not by reading the code.