proof-aware-crypto-tooling-.../provider
mrwulf 2dae2ca0db audit v3: paper-reality congruence + external-pointer integrity (Fable-5 Socratic pass)
Two Fable-5 inventory agents cross-checked every empirical claim in the
paper against code/deployed log, and every external pointer against the
live internet. Fixes on both sides:

CODE (system brought up to the paper's claims):
- SECURITY: pin-store mutation (incl. permanent poisoning) was reachable
  via receipts whose head signature FAILED verification in two of three
  consumer paths (attestation.py, cli.py) - an unauthenticated forged
  head at the pinned size could poison a consumer's pin forever and
  pollute the equivocation-evidence pair with an unverifiable head,
  contradicting SS5.4's 'validly signed' precondition and Prop 1.
  Both paths now gate the store on a verified Ed25519 head signature
  (logclient.py already did). Regression test added.
- Prop 2 made literally true: _normalize_certificate now derives the
  cleanliness verdict purely from (observed cone, local allowed set) in
  EVERY branch; the operator's axiom_status label is never copied (was
  passed through for non-proven certs), missing cone => unverifiable
  always. Labels can deny, never grant. Test added.
- webdocs: '/v1/sth-history: every head ever signed' -> 'the published
  head history'.

PAPER (claims brought down to reality):
- 'every head ever signed' -> the signed head history since publication
  began (heads for sizes 1-7 predate the mirror and were not retained).
- Run-3 bullet: 'independently checkable by diffing the two commit
  trees' was no longer reproducible (pre-rewrite objects discarded);
  now states the log-internal corroboration (identical cert lists and
  cones across leaves 4-7 vs 8-11) and that tree diffs are not public.
- Appendix A leaf block now actually verbatim: scheme
  openssl-ed25519, verified_backend serial/u64, real Lean version
  (4.30.0-rc2) instead of 4.x.y placeholder, leaf's actual axiom order
  (finalize/new/update), machine_protection note quoted, elisions
  marked; preamble wording matches.
- Appendix C upstream boundary reordered to check.sh's verbatim order.
- '27 lines - all annotation' -> honest description (axiom-list entries
  + operation reordering from one fork's black_box barrier).
- Prop 2 proof + App A: status label consulted only negatively.
- SS7: provenance fields noted as outside the signed payload; consumer
  chain relies on none of them.
- Bibliography: all 20 entries verified against DBLP/RFC-editor - zero
  errors; added missing page numbers to 6 entries; thebibliography
  width 19->20. All URLs verified public; no PlanetMacro leakage.

17 pages, 106 tests green, accumulator untouched (tree_size 12).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-09 21:33:28 +02:00
..
src/pacta_provider audit v3: paper-reality congruence + external-pointer integrity (Fable-5 Socratic pass) 2026-07-09 21:33:28 +02:00
pyproject.toml add nested proof check provider 2026-07-03 13:03:58 +02:00
README.md add transparency log trust provider 2026-07-03 14:09:34 +02:00

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.