proof-aware-crypto-tooling-.../provider
mrwulf a651a3b58c The LTL website: the accumulator drawn live, artifacts named unambiguously
The /docs route is now a real landing site (still one self-contained
HTML, inline CSS + inline SVG, zero external assets):

- One-sentence definition up top: what the LTL is and the cost
  asymmetry it exists for (one signature + a few hashes in
  milliseconds vs hours of theorem proving).
- THE GRAPHIC: the accumulator itself, rendered server-side from the
  LIVE log at page load - real leaf hashes, real internal nodes, the
  real root and signature. Green leaves are boundary-exact verified
  attestations; grey leaves are the historical audit-failure entries,
  labeled "kept forever - an append-only ledger does not erase its bad
  day". The signature box names the dogfood backend and the provider's
  self-inclusion check (the signature vouches for the code; the tree
  vouches for the signature's code).
- "What do I download?" - exactly three artifacts, numbered, each with
  what-it-is and where: (1) provider.ed25519.pub, the sole trust
  anchor, cross-checkable between this site and the GitHub mirror;
  (2) the attestation = the claim; (3) the receipt = the proof of
  inclusion. Plus the maximal-benefit path: clone the mirror, run
  verify.py --all, become a witness.
- Three usage lanes (quick check / zero-install audit / autonomous
  agent), the API, and the means / does-NOT-mean cards.

Rendered against the real 8-leaf log and content-asserted in tests'
presence. 54/54 green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-06 16:38:37 +02:00
..
src/pacta_provider The LTL website: the accumulator drawn live, artifacts named unambiguously 2026-07-06 16:38:37 +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.