You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reject the Unicode noncharacters, and record suiteRevision 6 at 153/153 (#4)
* fix(json): reject the Unicode noncharacters in every string literal
suiteRevision 6 makes the RFC 7493 section 2.1 exclusion normative: the sixty-six
noncharacters, U+FDD0 through U+FDEF and U+nFFFE and U+nFFFF in each of the
seventeen planes, are malformed wherever a string literal appears, at any depth
and in member-name as well as value position.
This checker admitted them, and the reason is worth recording because it was not
an oversight. The earlier text scoped its MUST to string literals being
well-formed sequences of Unicode scalar values, and a noncharacter is a scalar
value, so the narrower rule was implemented faithfully. What the revision changes
is the rule, not the reading: the strict-I-JSON label above that MUST had always
implied the wider RFC 7493 exclusion, and the revision closes the gap between the
label and the rule underneath it.
Both routes into a string body are covered, because the exclusion is over code
points and a producer reaches them either way: the raw UTF-8 byte, and the escape
including a surrogate pair resolving into a plane-end noncharacter. The plane-end
pairs differ only in their lowest bit, so one mask covers all thirty-four, and a
test walks the whole code space to confirm the predicate selects exactly sixty-six.
Refs in-toto/attestation#570.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat: record suiteRevision 6 at 153/153 and repin CI
The unchanged revision-5 checker scored 151/153. The depth-boundary pair ok-036
and bad-742 passed on the container-branch counter already in place; bad-743 and
bad-744 did not, and those two are what the previous commit fixes.
The record says plainly that this run is directed, and more so than revision 2
was: the rule was written and the vectors named before this checker ran, so what
it shows is that the corrected rule is implementable from the text, not that an
outside reader found something. Revision 5 is retired from continuous
verification and keeps its checkerCommit, 88c37d1, so its provenance stays
checkable after the pin moves. The workflow follows: suite pin, spec pin, the
compared report, and the parity string the corpus step greps for.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: README.md
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,6 +10,8 @@ An independent validity-gate checker for the **Adversarial Execution Evidence (A
10
10
11
11
**suiteRevision 5: 149/149** (35/35, 114/114) after a parser fix. The unchanged revision-3 build scored **148/149** against it, and the single miss is worth stating plainly because the causation runs the other way this time: the revision pins a nesting bound the earlier text did not state, this checker had picked 256, and the new `bad-741` vector found it. Not blind, and not a case of the two meeting. The bound was only the visible half. The revision also states the counting rule, and this parser had been incrementing per parsed value rather than per open container, which read exactly one level deeper than the spec rule on **every document in the corpus** — all 149 statements and every record payload inside them, measured on the raw bytes so the deliberately ill-formed vectors are covered too — because every deepest path in the corpus ends in a scalar. Changing only the constant scores 149/149 as well, and still rejects a statement at depth 128 that the spec calls valid. What keeps the corpus from telling the two fixes apart is not its maximum depth, since `bad-741`'s payload sits at 130, but that nothing in it sits at 128, the one depth where the two readings disagree: a scalar leaf inside 128 open containers reads as 129 to a per-value counter and 128 to a per-container one, and at 129 both reject. That boundary is pinned in this parser's own tests instead. The revision's other half, the encoding rules, needed no change here: this checker rejected ill-formed UTF-8, CESU-8, overlong forms and unpaired surrogate escapes from the first build.
12
12
13
+
**suiteRevision 6: 153/153** (36/36, 117/117) after implementing the noncharacter exclusion. The unchanged revision-5 build scored **151/153**. Two of the four new vectors are the depth-boundary pair, `ok-036` and `bad-742`, and the container-branch counter already handled both; the other two, `bad-743` and `bad-744`, carry Unicode noncharacters in a vocabulary label and a payload value, which this checker admitted. It admitted them because the earlier text scoped its MUST to well-formed sequences of Unicode scalar values, and a noncharacter is one; the revision widens the rule to the RFC 7493 section 2.1 exclusion the strict-I-JSON label had always implied. **This one is directed, and more so than revision 2 was:** the rule was written and the vectors named before this checker ran, so what it demonstrates is that the corrected rule is implementable from the text, not that an independent reader found it.
14
+
13
15
[PARITY-REPORT.md](PARITY-REPORT.md) carries the scores, the interpretation decisions the spec text forced, the four formerly-open corners and how each was closed, and the from-spec discipline attestation listing exactly what was and was not read for each revision. [NOTES.md](NOTES.md) compares the vendored spec against the branch-head spec.
14
16
15
17
No dependency on the reference implementation: this crate carries its own strict I-JSON parser, RFC 8785 canonicalization with ECMAScript number formatting, RFC 6962 domain-separated Merkle root over DSSE PAE bytes, run-binding derivation, and Ed25519 tier verification against the suite's seed-derived test key.
@@ -18,13 +20,13 @@ No dependency on the reference implementation: this crate carries its own strict
Copy file name to clipboardExpand all lines: reports/INDEX.json
+15-1Lines changed: 15 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -66,8 +66,22 @@
66
66
"vectors": 149,
67
67
"acceptParity": "35/35",
68
68
"rejectParity": "114/114",
69
+
"continuouslyVerified": false,
70
+
"note": "Revision 5 pins the two things the v0.6 text left open, encoding and nesting depth. The unchanged revision-3 checker scored 148/149 against it, missing only bad-741: this implementation had picked 256 where the text now says 128, and counted depth per parsed value where the text now says per open container. Both halves are fixed here. The constant alone would also have scored 149/149, which is why the boundary the corpus does not reach is pinned in the parser's own tests instead.",
"note": "Revision 5 pins the two things the v0.6 text left open, encoding and nesting depth. The unchanged revision-3 checker scored 148/149 against it, missing only bad-741: this implementation had picked 256 where the text now says 128, and counted depth per parsed value where the text now says per open container. Both halves are fixed here. The constant alone would also have scored 149/149, which is why the boundary the corpus does not reach is pinned in the parser's own tests instead."
84
+
"note": "Revision 6 adds the depth boundary pair and the noncharacter pair. The unchanged revision-5 checker scored 151/153 against it: ok-036 and bad-742 passed on the container-branch counter already in place, and bad-743 and bad-744 did not, because this checker did not implement the RFC 7493 section 2.1 noncharacter exclusion the revision makes normative. A directed fix, not a blind run: the rule was stated before this checker was run."
0 commit comments