proof-aware-crypto-tooling-.../provider
mrwulf 962c0fdd41 verify.py template: check the additive SLH-DSA head signature, fail-closed where it counts
The consumer verifier now judges the slh_dsa block on every head. The status
taxonomy is the design decision, so it is spelled out and each arm tested:

  ABSENT     head predates the second signature — allowed (additive posture,
             operator decision 2026-08-06); an append-only log keeps history.
  VALID      verified against provider.slhdsa.pub.
  INVALID    present and wrong — HARD FAILURE. A bad signature is never a
             degradation.
  WRONG-KEY  head names a different key than the mirror ships — hard failure.
  NO-PUBKEY  head claims the signature, mirror ships no key — broken
             publication, hard failure.
  TOOLING    OpenSSL < 3.5 cannot read SLH-DSA keys — honest degradation:
             one loud NOTE, never counted as verified, never failed; the
             required Ed25519 checks still gate the result.

verify_selftest.py gains two adversarial cases, both mutating a full mirror
copy: one flipped signature byte must fail naming slh_dsa:INVALID; deleting
provider.slhdsa.pub while heads claim the signature must fail NO-PUBKEY. On
mirrors without slh blocks the cases record as not-applicable rather than
silently passing. First selftest run caught my own marker bug — the case
grepped for the stored failure string, which is never printed, instead of
the printed status; the printed line is now the assertion target.

README template: SLH-DSA key row, honesty paragraph (verification proven for
both algorithms, signing for neither; leaves Ed25519-signed at issuance
only), and the hardcoded head size is GONE — the README now names no tree
size at all, so this staleness class dies with the instance (it said "tree
size 13" and would have shipped that under a 19-leaf head).

Template is deliberately ahead of the published mirror until the next
publication, which overwrites the mirror from here (the sync rule's
intended direction for pre-publication work). Proven against the scratch
19-leaf mirror: verify.py --all RESULT OK [full] with ABSENT on heads 8-13
and VALID on 14-19; selftest 13/13 GREEN. Backward compat proven against a
copy of the live 13-leaf mirror: RESULT OK [full], selftest GREEN with the
slh cases n/a. Suite 152/0/0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-07 15:16:58 +02:00
..
src/pacta_provider verify.py template: check the additive SLH-DSA head signature, fail-closed where it counts 2026-08-07 15:16:58 +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.