proof-aware-crypto-tooling-.../provider
mrwulf 6c65a53775 site rewrite: the trust ladder is the page's spine
Operator order: coherent, precise, accessible — an undergraduate CS
student must understand what the service provides, how to benefit, and
what to DO from each trust angle. The page now opens in plain terms
(what happened, why this site exists), keeps the precise one-sentence
as the second voice, and replaces 'Three ways to use it' with the
FIVE-rung trust ladder: (1) witness — hold the history honest, one
minute; (2) trust the reports, bind the operator — milliseconds;
(3) accept observations, reject judgment — re-derive verdicts from
recorded cones against your own card, the rung most people miss;
(4) replay the proofs yourself — ~30 min/library; (5) rebuild the whole
path — weeks, floor named (kernel/extractors/compiler; no rung 6).
Split-view comparison stated as orthogonal to all rungs. The API box is
demoted to 'For your tooling — the raw API' at the bottom with its
reason for existing stated (machine consumers; pacta builds on it).
All content guards keep their exact phrases; suite 154 green.
2026-08-16 21:00:18 +02:00
..
src/pacta_provider site rewrite: the trust ladder is the page's spine 2026-08-16 21:00:18 +02:00
pyproject.toml add nested proof check provider 2026-07-03 13:03:58 +02:00
README.md docs: the pre-Green full-scan repairs — ESTATE/llms/evidence to the 19-leaf world, leaf-index numbering unified, instruction traps closed 2026-08-16 18:32:37 +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 ~/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; heads are dual-sign capable with an additive SLH-DSA-SHA2-128s slot (proven verify path), and the ML-DSA/FIPS 204 slot stays honestly not_configured/unavailable — never silently filled. 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.