Lars, Guigui, all,

Measured here on the checker at c848fae, current main, with Python
3.11.15, cryptography 50.0.2 and PYTHONHASHSEED=0. I replaced all 59
signature.sig files in v1.4.0-conformance with random 64-byte values.

- With the manifest untouched, the run stops at manifest
  verification: 59 hash mismatches, exit 1.
- With those 59 manifest entries re-pinned to the new bytes, the run
  is 66/66 cases and 73/73 receipts, exit 0, and the output is the
  same as the baseline run.

So on the current checker a swapped detached signature is refused,
but by the pin and not by any signature check, and once the pin moves
with it the verdict does not change. That fits your wording for 6: a
file no check reads gets its own state, and the record says which
ground refused.

This is Guigui's checker run by another operator, so a reproduction,
not an independent result.

Nicolás

El mié, 14 oct 2026 a la(s) 11:56 a.m., Lars Kersten Kroehl (
lars@moltrust.ch) escribió:

> Guigui,
>
> The checker never reads signature.sig. That measurement from 0056 did not
> make it into the fold; replacing the file left the run at 66/66 with exit 0.
>
> The v2 criteria pin it and list it. Criterion 1 covers its bytes,
> criterion 2 puts its identifier in the closed manifest, and criterion 6
> lets it be declared as carried inline. None of them requires the checker to
> open it, so a file can be pinned, manifested, declared carried, and still
> never enter the verdict.
>
> Proposed wording alongside criterion 6: for each artifact declared carried
> inline, the record states whether the checker read it. An artifact that no
> check consumes gets its own state, distinct from carried.
>
> One line in your opening should also be narrower. My run showed the
> embedded Ed25519-over-JCS signature enforced and a forged embedded
> signature rejected. The detached file was not part of that result.
>
> Lars
>
> Am 13.10.2026 um 03:13 schrieb Guigui Wang <wangguigui@correctover.com>:
>
> Lars, all,
>
> Thank you for the independent re-runs and the line-level review over the
> past day. To anchor the thanks to specifics rather than politeness:
>
> - Sankalp Gilda re-ran the suite unaffiliated with us: 66/66 cases, 1549
> receipt checks, exit 0, with a signature-mutation negative control
> correctly refused.
> - Lars Kroehl reproduced byte-identical output across runs with
> PYTHONHASHSEED=2, confirming the embedded Ed25519-over-JCS signature is
> enforced and a forged signature is rejected.
> - Roel Schuurkes gave three wording refinements, explicitly offered as
> wording rather than as adoption.
> - The other two corpora in the thread (EATF; disensor) likewise received
> non-author reruns, which is the intake question this thread is actually
> about.
>
> Two engineering notes Lars raised concern the MIT-licensed reference
> checker only - a one-directional manifest check, a self-proving footer
> total, and unordered-set stdout. The production verifier is a separate,
> closed codebase. Those three notes are precisely what criteria 2, 4 and 10
> below refuse at intake; a patched revision of the MIT reference checker
> will follow in the same CC0 repository, with no change to any corpus bytes.
>
> Using the 0057 text as the base (per Lars), folding in Roel's three
> wording points and the four reproduction gaps Templeman listed, which 0066
> already carried into criteria and rejection grounds, below is a
> consolidated v2. Changes versus 0057: (a) the admitted population is named
> up front; (b) the independent recount names the decision rule and inputs a
> refusal is recomputed from; (c) byte identity and replay stability are
> separate criteria; (d) checker provenance also pins helpers fetched at run
> time; (e) rejection grounds are enumerated rather than implied.
>
> Intake criteria for a submitted conformance result, v2
>
> Terminology. "Admitted population" means the set of members a submitted
> record makes claims about, bounded exactly by the closed manifest in
> criterion 2. A member present on disk but outside that boundary is not
> admitted, regardless of what the tooling printed.
>
> 1. Byte pinning (fixture bytes). Every member of the admitted population
> is pinned by a digest over its exact bytes, and a corpus digest covers the
> full tree together with its manifest. A reader refuses any member whose
> bytes do not match the pin. A digest covers the bytes that were available;
> by itself it says nothing about which members a reported result concerns,
> which criterion 2 settles.
>
> 2. Closed manifest (inventory of unique identifiers). The record carries a
> closed manifest of unique case or report identifiers, checked in both
> directions. The reader compares the returned population against the
> manifest and refuses, with the rejection ground named, when a member is (i)
> missing from the population, (ii) duplicated, or (iii) present on disk but
> absent from the manifest. No one-directional acceptance.
>
> 3. Selector. Alongside the digest the record names which members were
> selected, by what expression, and how many matched. A selection resolving
> to zero reports, or to more than one where exactly one is required, is
> refused at intake rather than silently bound; the requested-member-absent
> and requested-member-matching-more-than-once cases each carry their own
> rejection ground.
>
> 4. Independent recount, with decision rule. The reader recounts outcomes
> from the per-case records and never takes a printed summary line as the
> result. The printed total is one more value compared against the recount;
> any divergence is a refusal with both numbers recorded. The per-case lines,
> the aggregate line and the exit code are all carried, so the finding does
> not rest on one line. For each refusal the record names the decision rule
> and the exact inputs it was recomputed from, so a party holding only the
> pinned bytes can recompute the refusal without the original tooling.
>
> 5. Native record carried unaltered. Native verdicts, reasons and process
> status are carried unchanged.
>
> 6. Per-observation carry declaration. For each observation the record
> states one of three states: carried inline, referenced by digest, or
> absent. An observation declared inline and not present is a fail-closed
> refusal.
>
> 7. Anchor. The submitter declares an anchor carrying enough data to
> distinguish an availability failure (the reference does not resolve) from
> an integrity failure (it resolves but the digest does not match), and names
> the verdict for each. A suite anchored outside this group's registry stays
> admissible as long as its anchor is declared and reachable.
>
> 8. Checker and helper provenance. The checker is named by an immutable
> source revision and the exact command run, with runtime and dependencies
> named rather than inherited from whichever reader ran first. Any helper
> script, fixture fetcher or other artifact acquired at run time is named by
> both its acquisition URI and a content digest; an unresolvable helper or a
> digest mismatch is a refusal, never a silent fallback.
>
> 9. Canonicalization, numeric profile and digest inputs are declared, not
> inherited. The encoding identifier is drawn from a closed set, and a reader
> that does not implement the declared encoding rejects the record. Every
> digest offered as evidence declares its exact input serialization; a digest
> whose input serialization is undeclared stays outside the record.
>
> 10. Replay stability, distinct from byte identity. Byte identity - the
> same bytes always produce the same digest - and replay stability - the same
> pinned inputs produce byte-identical output across independent processes -
> are separate claims and are recorded separately. Where stdout or another
> unordered stream is digested, the record declares the hash seed and the
> ordering used; output that varies across processes with no declared cause
> is a refusal.
>
> 11. Exposure and fault separation. The record states whether the expected
> answers were visible to the implementer before the run. Reproducing
> recorded answers and detecting an injected fault are separate claims kept
> in separate records, even when one suite produces both; each deliberate
> fault has its own result, separate from the reproduction result and the
> exposure declaration.
>
> 12. Scope. The record states what the suite establishes and what it leaves
> open. It does not claim coverage of the whole attack surface, does not rank
> implementations, makes no claim about threats outside the corpus, and does
> not establish that an action happened or that its actor had authority;
> these limits sit beside the availability and integrity outcomes the record
> does establish.
>
> 13. The criteria name no implementation. The canonicalization-v1 subset
> (RFC 8785 JCS) enters as an instance under criterion 9, not as the rule
> itself. The Ed25519-signed receipt corpus, whose manifest pins every file
> by SHA-256, is offered as the first suite admitted under the full set.
>
> Line comments welcome; if there are no objections to the structure, the
> four v2 deltas (terminology, decision-rule recount, identity/stability
> split, helper pinning) are the only parts that need close reading.
>
> Guigui Wang | Correctover
> wangguigui@correctover.com
>
>
>

-- 

Nicolás Rocchia
disensor.dev · San Francisco, Córdoba, Argentina
