mirror of
https://github.com/saymrwulf/fips205-slhdsa-verified.git
synced 2026-09-04 20:03:44 +00:00
mrwulf
7ebf9495d3
Round-8 estate review (GPT-5.6): this repository shipped a
FunsExternal_Template.lean / FunsExternal.lean pair and NO correspondence
check at all. This commit explains why, and fixes the cause rather than
bolting a check onto a missing input.
THE TEMPLATE WAS BEING DELETED. check.sh removed `*_Template.lean` on every
run and .gitignore excluded it. The stated reason was sound — "the verdict must
depend on COMMITTED BYTES, never on untracked build state", and an untracked
file on LEAN_PATH is exactly that problem. But it is the weaker of the two
available remedies. The ed25519 forks face the identical choice and COMMIT AND
PIN their templates, which removes the untracked state just as completely and
keeps the evidence.
The evidence is the point. The template is Aeneas's own statement of what the
extracted Rust needs from outside, and it is the ONLY artifact against which
"does the hand-written model ANSWER the extraction?" can be asked. Deleting it
made that question unaskable here — which is precisely why no check existed.
· template committed and pinned in model_integrity_sha256
· .gitignore no longer excludes it
· check.sh no longer deletes it, and says why at length
· Phase 0d runs model-correspondence.py — the forks' scanner, including both
round-8 corrections: a named Lean `section` does not qualify declaration
names, and an EXTRA AXIOM in the model (an assumption no template asks for)
fails rather than passing as a silent row
· MODEL-CORRESPONDENCE.txt committed, pinned, and compared byte-for-byte
Result: 11 externals, every one answered by the pinned model, no UNRESOLVED and
no EXTRA-AXIOM. Negative-tested — deleting one `axiom` from the model yields
`verify_mono.oracle.h_msg|UNRESOLVED` and a non-zero exit; restoring it returns
to green.
AND A REPRODUCIBILITY RESULT, obtained while recovering the deleted template.
charon is not available on this machine (the same wall the reviewer hit), but
SlhVerify.llbc IS committed and Aeneas is installed, so extraction step [2/2]
was re-run alone from the committed LLBC:
Types.lean: IDENTICAL Funs.lean: IDENTICAL
The LLBC -> Lean half of the extraction reproduces byte-for-byte from committed
inputs, on demand, by anyone with Aeneas and this repository. This does NOT
close `slh-extraction-unreproduced`: the Rust -> LLBC half still requires
charon, and this was still run by the author. Half the chain, verifiable today.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
12 lines
716 B
Text
12 lines
716 B
Text
SlhVerify/FunsExternal|Array.Insts.ZeroizeZeroize.zeroize|MODEL
|
|
SlhVerify/FunsExternal|U32.Insts.CoreIterRangeStep.backward_checked|MODEL
|
|
SlhVerify/FunsExternal|U32.Insts.CoreIterRangeStep.forward_checked|MODEL
|
|
SlhVerify/FunsExternal|U32.Insts.CoreIterRangeStep.steps_between|MODEL
|
|
SlhVerify/FunsExternal|verify_mono.oracle.f|MODEL
|
|
SlhVerify/FunsExternal|verify_mono.oracle.h|MODEL
|
|
SlhVerify/FunsExternal|verify_mono.oracle.h_msg|MODEL
|
|
SlhVerify/FunsExternal|verify_mono.oracle.t_l|MODEL
|
|
SlhVerify/FunsExternal|verify_mono.oracle.t_len|MODEL
|
|
SlhVerify/FunsExternal|zeroize.Zeroize.Blanket.zeroize|MODEL
|
|
SlhVerify/FunsExternal|zeroize.__internal.AssertZeroize.Blanket.zeroize_or_on_drop|MODEL
|
|
CORRESPONDENCE-COUNT|11
|