proof-aware-crypto-tooling-.../evidence/latest-sth.yaml

schema_version: 1
type: pacta.transparency.signed_tree_head.v1
log_id: 205e4c389cb143e08f0d2d58bdc8e425e47e3cbe7f2108cc58bbe835d2cc41d7
tree_size: 8
timestamp: '2026-07-06T12:53:09Z'
root_hash: 9a15b9a1379edc07ae43d3fc61b52dc4446b56770bff6538e88ed98746ac2283
hash_algorithm: RFC9162_SHA256
signatures:
  ed25519:
    scheme: openssl-ed25519
    status: signed
    payload_digest_sha256: d5d25db2c90f0246cc10d10f912085b81c60d2a324354b5abecfdbeb8bd17ee2
    signature_base64: sI4rWnWMrX0zDaN8jofBwSuExKg1e0cmZV3OPaulbXDV97yz95aSo0Gnrfd1En2vyyV1qoEXdTAY9NDgvA8xBA==
    public_key_fingerprint_sha256: 874c8a008a607021528b2493fa1caf059f9d5c123d29193dfabc09a6d1e7a56a
  ml_dsa:
    scheme: ML-DSA-65
    standard: FIPS 204
    status: not_configured
    reason: A backend appears available, but no ML-DSA signing key was configured
      for this log.
REAL EVIDENCE: guarded replay of all four repos, attested, logged, dogfooded The provider ran its full honest replay against the four verified repositories on this machine - every Lean compile and axiom audit routed through lean-guard (memory-capped, core-pinned, single-flight, ~30 min per fork) - and the results are now shipped under evidence/: - 16/16 certificates proven per fork, every axiom cone boundary-exact (the four apex tiers carry their fork's documented SHA-512/wire boundary axiom-for-axiom), each attestation pinned to the exact repo commit (dalek 8ded7bc, anza 673c15e, risc0 98a13a6, betrusted 81f614a) and Ed25519-signed. - All four appended to the persistent transparency log. The log holds EIGHT leaves: the first four are the initial run's attestations, which honestly recorded an AUDIT FAILURE (the two pacta bugs fixed in e87f0e8) - an append-only trust ledger keeps its bad day, and the fixed run's leaves sit beside it. - Every receipt re-verified through the FULL stack: dogfood verifier (backend verified-dalek-serial recorded), STH pin store, freshness policy. Receipts are freshly issued against the final tree (a stale mid-run receipt tripped the pin store's rollback defense exactly as designed; the rollback diagnostic now hints at idempotent re-issue). - The capstone consequence ran for real: pacta agent with trusted provider + signature via the proven path + required receipt + pin store + --require-verified-verifier built the R4-gated library capsule from ATTESTED evidence (no local Lean replay needed by the consuming agent). Docs and teaching updated against the real artifacts: evidence/README (inventory + re-verify instructions), README "Real Evidence" section, lecture 5 now re-derives 16/16 verdicts from the REAL dalek attestation (signature checked on the proven path, provider labels ignored), and lecture 6 verifies all four REAL receipts and walks a fresh pin store over them. Every changed notebook cell executed before commit. 49/49 tests green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> 2026-07-06 12:54:48 +00:00			`schema_version: 1`
			`type: pacta.transparency.signed_tree_head.v1`
			`log_id: 205e4c389cb143e08f0d2d58bdc8e425e47e3cbe7f2108cc58bbe835d2cc41d7`
			`tree_size: 8`
			`timestamp: '2026-07-06T12:53:09Z'`
			`root_hash: 9a15b9a1379edc07ae43d3fc61b52dc4446b56770bff6538e88ed98746ac2283`
			`hash_algorithm: RFC9162_SHA256`
			`signatures:`
			`ed25519:`
			`scheme: openssl-ed25519`
			`status: signed`
			`payload_digest_sha256: d5d25db2c90f0246cc10d10f912085b81c60d2a324354b5abecfdbeb8bd17ee2`
			`signature_base64: sI4rWnWMrX0zDaN8jofBwSuExKg1e0cmZV3OPaulbXDV97yz95aSo0Gnrfd1En2vyyV1qoEXdTAY9NDgvA8xBA==`
			`public_key_fingerprint_sha256: 874c8a008a607021528b2493fa1caf059f9d5c123d29193dfabc09a6d1e7a56a`
			`ml_dsa:`
			`scheme: ML-DSA-65`
			`standard: FIPS 204`
			`status: not_configured`
			`reason: A backend appears available, but no ML-DSA signing key was configured`
			`for this log.`