Repository navigation
Implementation findings from the Go verifier (#444): 26 items #448
Description
#444 is the first independent implementation of v0.2: a Go verifier written from the spec, schemas and vectors alone, agreeing on 262 of 262 judged cases against 63f4d15 and trace-tests v0.6.1. It reported 26 findings. This issue tracks all of them in one place.
Status key: V = checked against the artifact at 63f4d15 and current main (11c0868); S = mapped by search only, not yet checked.
Two of them need a decision rather than a fix:
- 21, Level 2 is unreachable with the published flow (V). The anchor leaf is the complete signed record (
registry-anchor-v1.md:42), the signature coverstransparency(§3.2.2), and TR-ANC-001 requirestransparencyto name the entry that anchors it (§6). The record has to name an entry that does not exist yet;docs/tutorials/anchoring-to-the-registry.md:118already says so. trace-tests#92 acknowledged it on 2026-09-24 and trace-registry#102 only moves the leaf from E to R, which does not break the cycle. None of the three anchored claims in trace-registry carriestransparency, and two of them leaf the envelope rather than the record. - 19, Anchor Format §1 is defined by a Python call (V). The four prose rules do not pin short escapes, lowercase hex, escaping U+007F, surrogate pairs for non-BMP characters, or
-0parsing to0;json.dumps(..., sort_keys=True, separators=(",",":"), ensure_ascii=True)does all five.
| # | Finding | Status | Covered by | Home |
|---|---|---|---|---|
| 1 | ES256/ES384 embedded signature: raw r||s or DER not stated |
S | none (#401 covers base64url only) | trace-spec |
| 2 | trace-tests schema copy lacks canonicalizableValue |
V | none | trace-tests |
| 3 | verifier-compatibility README says no normative text; §3.3 now has it | V | related #116 | trace-spec |
| 4 | verifier-compat 06, 07, 11 refused by the membership check alone | V for 06 | partly: KNOWN_THIN records 06 only |
trace-spec |
| 5 | TR-SCA-002 and TR-TXN-001 docs say sha256 only; schema allows sha384 | V | none (#438 fixes the same drift here) | trace-tests |
| 6 | cMCP RuntimeClaim unverifiable; valid_cmcp_runtime.json signature is unsigned-test-vector |
V | none | trace-spec, trace-tests |
| 7 | openshell vector fails TR-APR-002 by the suite's own docs | V | known: trace-tests#63, #64; the valid_ name is the defect |
trace-tests |
| 8 | no vector has an expected result above level 0; vectors distinguish 4 of the 25 checks that apply to a plain record (TR-ENV-001, TR-POL-003, TR-SIG-005, TR-APR-002) | V (level part); count by the author's published mutation method (go run ./cmd/trace-conformance), not rerun by us |
related trace-tests#8, #124, #186 | trace-tests |
| 9 | delegation two-vectors-per-rule claim confirmed | n/a | positive | none |
| 10 | no revocation vector with a validly EC-signed bundle | S | none | trace-spec |
| 11 | three build-provenance rules caught by one vector each | S | related #166, #186 | trace-spec |
| 12 | citation-resolution evidence is Python-specific (KeyError) |
V | none | trace-spec |
| 13 | CHAP prev_hash form and audit/<seq> convention decided by data |
S | related #351 | trace-spec |
| 14 | action-receipt vocabulary and age boundary set by vectors | S | related #178 | trace-spec |
| 15 | GapDisclosure digest pre-image unstated | S | none | trace-spec |
| 16 | Acta README and crosswalk link trace-v0.1.md §3.3.2 | V | none | trace-spec |
| 17 | no vector for the GapDisclosure policy bound | S | none | trace-spec |
| 18 | JWS and COSE_Sign1 envelopes named, not specified | S | none | trace-spec |
| 19 | Anchor §1 defined by the Python call | V | none | trace-spec |
| 20 | registry entries carry canonicalization_id, mmr_checkpoint; §4 says "exactly these fields" |
V | none | trace-spec |
| 21 | Level 2 unreachable (circular transparency) |
V | trace-tests#92, #280, trace-registry#102 (none fixes it) | trace-spec |
| 22 | no TR-ANC-002 vectors; real anchors single-leaf and ASCII-only | V | none | trace-tests |
| 23 | levels.md says all-zero measurement invalid at L1; tr-rte.md says it passes | V | #240 fixed trace-spec only | trace-tests |
| 24 | tr-apr.md lists a float as a TR-APR-004 negative; 1784999900.0 has the same JCS bytes |
V | related #247, #404 | trace-tests, after #404 |
| 25 | ECDSA high-S acceptance unstated | S | none | trace-spec |
| 26 | does §3.2.2's integer rule reach Acta and CHAP objects cited by digest | S | partly #247, #404 | trace-spec |
Items marked V with no covering issue (2, 5, 16, 19, 20, 22, 23) are small, checkable fixes. Each S item gets checked before any fix is proposed for it.
Activity
dinakarjs commentedon Oct 3, 2026
Following your email, I audited item11 at trace-spec
aa5c350dbdc9b8337cfa8e7d773e7c0353a5d523, including the six depth vectors introduced by #166 and the current #186 adequacy criteria.dependency_attestation_missingbuilder; named unresolved evidencedependency_publisher_untrustedresolved_dependencies_absentbuilder; named unresolved evidenceAll 18 fixture/depth comparisons agree; the test module passes 49/49 on Python3.12.14 / pytest9.1.1. Each check is independently load-bearing. One fixture per rule is not itself a violation of this set's boundary-based margin criterion. Go v0.1.0 at
4e38ea2d3ed70434d9dd145e0f65269b5b2ec0ffalso implements these checks and compares verified depth/unresolved evidence; that source was inspected, not executed.A narrower gap is reproducible: replace only the absent-dependencies check with missing-key-only. All existing 18 comparisons and 49 tests still pass. An in-memory copy of control01 with only
resolvedDependencieschanged to[]separates them: the reference reportsbuilderplusresolved_dependencies_absent, while the weakened verifier incorrectly reportstransitive. Both still accept, so accept/reject alone cannot catch it.Proposed scope: pair one explicit-empty-list fixture with existing accepting control01, assert the complete appraisal, and require that missing-key-only weakening fails that pair. Preserve the current absence/downgrade behavior and six fixtures; no wire or normative changes.
Before implementation, could you confirm the explicit-empty-list expectation for this informative corpus and identify the review owner? I am not treating the spec as universally forbidding empty input sets in genuinely dependency-free builds. No fixture implementation or ownership is claimed yet.
imran-siddique commentedon Oct 5, 2026
@dinakarjs confirmed: an explicit
resolvedDependencies: []stays atbuilderwithresolved_dependencies_absent. The transitive row ofdocs/verification.mdalready says so ("or the attestation declares no inputs at all"), and the oracle's predicate treats an empty list the same way. A producer stating it had no inputs is not evidence that the build had none, so a dependency-free build tops out atbuilderin this corpus. That is the reading to pin.Go ahead with the pair against control01 and the missing-key-only mutant, and request my review on the PR. Can you have it up by 12 October?
test: catch explicit empty build dependencies in depth corpus
test: catch explicit empty build dependencies in depth corpus (#475)