IPX: fingerprint the consumed spool prefix in replay checkpoints #199
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
feature
good first issue
help wanted
invalid
question
refactor
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nsaspy/hackmode!199
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/issue-182"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #182
Bug
replay-ipx-http-spoolresumed purely from the stored byte offset of the latest capture checkpoint. Nothing tied that offset to the actual spool file content, so a replaced, restored-from-backup, or re-exported spool file with the same operation/capture-session/source identity was silently decoded from unrelated bytes into canonical exchange evidence.Fix
make-capture-checkpoint-recordgains validated optionalspool-fingerprint(SHA-256 hex of the consumed spool prefix[0,offset)) andspool-sizepayload fields.ipx-persist-checkpointcomputes and records both for every new checkpoint.replay-ipx-http-spoolverifies before resuming:ipx-spool-fingerprint-mismatchcondition;RED-first verification
Two regression tests added to
tests/ipx-replay.lisp: after a checkpoint, replacing the spool with different content and shortening it below the recorded offset must each signalipx-spool-fingerprint-mismatchinstead of decoding garbage.Local exact-head core gate (mirror of core.yml, pinned deps): all ten Hackmode test suites pass at commit time, including the new regressions. ironclad declared in hackmode.asd (already a transitive starintel dependency).
Boundary
Replay/checkpoint correctness only. No capture-provider, expert, or database authority changes; no API behavior change for fingerprint-carrying checkpoints.