proof-aware-crypto-tooling-.../provider/README.md
mrwulf b497b00c73 docs: the pre-Green full-scan repairs — ESTATE/llms/evidence to the 19-leaf world, leaf-index numbering unified, instruction traps closed
ESTATE.md was still the 2026-07-22 snapshot (13 leaves, v0.9, 'SLH-DSA
NOT in the log'); llms.txt still said thirteen leaves, 23 pages, and
linked the retired /paper/v0.x routes; README repeated the stdlib-only
verify.py trap the site just fixed; evidence/README called the July
capture's 16/16 attestations 'definitive' and its 8-leaf state current.
All brought to truth. Entry numbering standardized on 0-based leaf
index with 'the thirteenth entry' as the ordinal gloss (docs, lab
manual, security note, mirror README template). Operator-machine path
removed from provider/README.
2026-08-16 18:32:37 +02:00

49 lines
2.6 KiB
Markdown

# 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
```bash
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:
```bash
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.