risc0-ed25519-verified/verification/GEN-MODEL.sha256

13 lines
1.1 KiB
Text
Raw Permalink Normal View History

correspondence: a named section is not a namespace; an extra axiom is a failure Round-8 review (GPT-5.6, register key `section-prefix-bug`, CRITICAL). Reproduced here exactly before fixing. model-correspondence.py treated `namespace`, `section` and `end` as one event class and pushed a named section onto the fully-qualified-name prefix. Lean does not: `section Foo` opens a scope for `variable`/`open` and gives `end Foo` a label; it does not turn `bar` into `Foo.bar`. Given a template reading section Foo axiom bar : Nat end Foo the scanner reported `Foo.bar`, `--names` handed Phase 2d only `Foo.bar`, Lean resolved an unrelated `Foo.bar` definition elsewhere in the corpus, and the verdict came back PROVEN. The axiom the extraction ACTUALLY depends on was never queried. This survived both the fail-closed rewrite and the new Lean-semantic phase, in a scanner rewritten that same week specifically to stop dropping things. AND THE REASON IT STAYED SILENT, which is the half worth keeping. The real external did not vanish — it landed in the table as EXTRA, the one verdict that could not fail. A silent bucket beside a fail-closed parser is a slower way of dropping things. An extra AXIOM is now EXTRA-AXIOM and stops the button: the model exists to answer the template, so an assumption nothing asks for is either a parse we got wrong or an assumption nobody governs. Extra definitions stay tolerated; helpers in a model file are ordinary. That gate fired on the real corpora on its first run. Each fork's hand-maintained gen/CurveField/FunsExternal.lean carried AVX2/AVX512 backend axioms present in no template, no proof, no cone and no allowlist — dead assumptions in a pinned trusted-base file, reported as EXTRA and therefore invisible. extract.sh:16 confirms these files are never overwritten by extraction, so they were hand-written and are removed here: dalek 2, anza 3, risc0 4, betrusted 4 Nothing referenced them, so no certificate's cone changes; the trusted base simply gets smaller. Table rows 64->62, 51->48, 57->53, 56->52, and Phase 2d independently resolved 62/48/53/52 externals against the regenerated tables. GEN-MODEL.sha256 and HARNESS.sha256 both move: the model bytes changed, and the harness pins the table and the gen manifest themselves. Certified: round-10 sweep, 2h53m, ten instruments in each of four forks, 40/40 GREEN, 0 failing, 0 resource-limited. A full run was required — the --audit-only staleness gate correctly refused after a source change. Registered in formal-verification-control/review-findings.tsv as `section-prefix-bug` and `dead-model-axioms`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-02 19:29:54 +00:00
47bd1a4f2522b07a415eadafa25254a82da8061bb38975d07418735a175d8958 CurveField/FunsExternal.lean
verification: bind the statements, the specifications, and the model (P1-a) Phases 3/3b establish what each certificate RESTS ON. Neither says what it SAYS, nor what it is ABOUT. A certificate gutted to a tautology of the same axiom cone passes both; so does one whose reference definition has been redefined to BE the extracted code, at which point the theorem reads `loop = loop` and every cone is byte-identical. Phase 3c closes that. Proofs/Audit.lean emits a canonical block holding the policy constants, every certificate's fully-elaborated statement (pp.all, so implicit arguments, instances and universe levels are visible), and the body of every specification constant transitively reachable from those statements. Its SHA-256 is pinned in check.sh and the block itself is committed as AUDIT-MANIFEST.txt, so a mismatch is DIFFED, not merely reported. 31 certificates, 68 specification constants per repository. Two tiers, not one. These forks have an arithmetic tier that must stay oracle-free and an apex tier carrying this fork's hash and wire-format axioms, and the apex boundary genuinely differs per fork (dalek 8 extra names, anza 4, risc0 and betrusted 5). One shared constant would have widened the arithmetic tier to accept hash oracles, which is the most valuable property these repos have. Each auditor is generated from its own repository's policy. Phase 0b pins the extracted model. This was not a precaution: risc0 and betrusted were observed emitting BYTE-IDENTICAL audit-manifest digests (6c821b8e…) while shipping demonstrably different extracted models, their point-doubling routines differing in operation order. A statement names an extracted function; it does not contain that function's body. Binding statements is not binding the subject. Membership derives from the filesystem, so a new model file fails closed. selftest-statements.sh attacks both phases with ten cases, each asserting a specific diagnostic: an edited model body, an unlisted model file, a widened policy, a hand-edited committed block, a certificate dropped from the auditor WITH the digest refreshed to match, and a gutted statement whose cone is unchanged. It lifts the phases out of check.sh at run time, so it attacks the shipping gate rather than a copy. Two bugs found and fixed during that testing, both mine: Phase 3c read `$0` after `cd "$AENEAS_LEAN"`, and $0 is the caller's relative path; and the axgate self-test compared the tree against a pristine checkout rather than against how it found it. A third expectation was wrong rather than the code — widening the apex boundary is caught by the exact-cone requirement before the digest ever runs, which is a stronger rejection, and the test now says so. All sixteen runs green at these commits: four main buttons, four axgate self-tests, four binding self-tests, four scalar buttons. TRUSTED-BASE.md records what this binds and, at equal length, what it does not: a digest binds identity, not meaning; an author can rotate the pins in one commit and is caught by review, not by the script; and pinning the model says nothing about whether Charon and Aeneas translated the Rust faithfully. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 22:38:20 +00:00
c9cc095ef7ec6e1c1e914aec280468ad6bc27bdfb8c7eb0c2b647060a5cc7076 CurveField/FunsExternal_Template.lean
418682624b1591b6b7f5d245efa4312498255459ce47d9b507ab77d32439484a CurveField/Funs.lean
d197d7b9fe515863784eeee59a2fbb69735d10ebcf5cc4e03feb3afbeb53a2b7 CurveField/TypesExternal.lean
4560fc87c6156df16c34117db0817dc0926709f884728d9ca907985cbf931c6c CurveField/TypesExternal_Template.lean
f17fd167be6e273fe6379196f0e931dabb963d5f7c9d27efbd1e3deab74a8e1e CurveField/Types.lean
11e90fcaf1a33a7f66b1d9eaebcd4b69db23837a027ff56f64941084d223512b CurveSig/FunsExternal.lean
3fa865dca7f03dcfdd68533321a6669d73e8698f2780b6934ff135cef0cd8f38 CurveSig/FunsExternal_Template.lean
28ed4991ccf04ffaf66d0f47bd1cc90dec9029ba7381d54ad1d8a3d684d074b3 CurveSig/Funs.lean
2358490d0b10aa95cfd951e65f9d52988da52740a5c8af209cd9e0bc45a26734 CurveSig/TypesExternal.lean
fe94bba57cba8a40aa6195f505eb56107c06f92be7dfc04931a7c05d104ae76a CurveSig/TypesExternal_Template.lean
29e72d1c365464b009a38e2310cebbf285e96c296e59ed098e06e647bbc5ffe6 CurveSig/Types.lean