mrwulf
ab629f34d8
Closes the two halves of replay-pipeline-lags-hardened-forks. (1) The generic replay compiled every .lean under verification/, including the P1-b kernel-gate instruments (Proofs/Inventory*.lean) that read other modules' object files via readModuleData and only run inside the button's environment; it died with "object file does not exist". New RepoConfig.replay_exclude (globs, per repo, in the config where a reviewer sees them) filters the compile; every exclusion actually applied is recorded in the attestation's replay.instruments_excluded, so the LEAF discloses what its replay did not compile — a silent exclusion here would be the estate's oldest defect class. The replay checks the certificates; the deeper self-auditing gates are the repository's own and run there. (2) The ed25519 profile's default list still carried the 16 pre-hardening certificates, so a successful replay would have attested 16 and the whole 16->44 point of the re-attestation would have been lost silently. Each fork entry now carries its own 44 — 27 main + 4 apex + 13 scalar — MEASURED from the fork's two buttons (CERTS arrays; apex recovered by the same pattern Phase 3c itself uses), never hand-typed. Correction to the plan on the way through: the plan said 40; the apex tier makes it 44. Suite: 152 passed, 0 failed, 0 skipped. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src/pacta_provider | ||
| pyproject.toml | ||
| README.md | ||
PACTA Proof Check Provider
This nested project is a prototype third-party proof-checking service. It reuses host Lean/Aeneas infrastructure, runs portable PACTA replay/audit checks, and emits signed attestation certificates.
It does not modify anything outside this repository. It may read configured toolchains such as /Users/oho/GitClone/ClaudeCodeProjects/your-lean-project/aeneas-toolchain/env.sh.
It can also maintain a local transparency log. The log is an RFC 9162-style Merkle accumulator over signed attestations. It emits Signed Tree Heads with Ed25519 today and records an ML-DSA/FIPS 204 signature slot as unavailable unless a real backend is present. Agents that require both signatures must reject such receipts.
Commands
PYTHONPATH=src:provider/src python -m pacta_provider discover
PYTHONPATH=src:provider/src python -m pacta_provider init-key --key-dir provider/state/demo-provider
PYTHONPATH=src:provider/src python -m pacta_provider check \
--config examples/repos.yaml \
--repo-name dalek-ed25519-verified \
--repo repos/dalek-ed25519-verified \
--provider local-pacta-provider \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub \
--out provider/out/dalek.attestation.yaml
Transparency log:
PYTHONPATH=src:provider/src python -m pacta_provider log-init \
--log-dir provider/state/transparency-log \
--provider local-pacta-provider \
--public-key provider/state/demo-provider/provider.ed25519.pub
PYTHONPATH=src:provider/src python -m pacta_provider log-append \
--log-dir provider/state/transparency-log \
--attestation provider/out/dalek.attestation.yaml \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub \
--out provider/out/dalek.receipt.yaml
PYTHONPATH=src:provider/src python -m pacta_provider log-sth \
--log-dir provider/state/transparency-log \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub
The resulting certificate can be consumed by pacta with --attestation, --trust-attestation-provider, and --attestation-public-key.
The receipt can be consumed with --transparency-receipt, --transparency-log-public-key, and --require-transparency-receipt.
The private key must remain provider-side. Downstream agents only need the public key, the inclusion receipt, and a policy decision that the provider name/log key is trusted.