proofbundle 0.3.0__tar.gz

proofbundle-0.3.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Konrad Gruszka
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

proofbundle-0.3.0/PKG-INFO

@@ -0,0 +1,291 @@
+Metadata-Version: 2.4
+Name: proofbundle
+Version: 0.3.0
+Summary: Emit and verify portable cryptographic evidence bundles, offline: Ed25519 + RFC 6962 Merkle + optional SD-JWT.
+Author: Konrad Gruszka
+License: MIT
+Project-URL: Homepage, https://b7n0de.com
+Project-URL: Repository, https://github.com/b7n0de/proofbundle
+Project-URL: Issues, https://github.com/b7n0de/proofbundle/issues
+Project-URL: Changelog, https://github.com/b7n0de/proofbundle/blob/main/CHANGELOG.md
+Project-URL: Documentation, https://github.com/b7n0de/proofbundle#readme
+Keywords: cryptography,merkle,transparency-log,ed25519,sd-jwt,verifiable-credentials,attestation,provenance,rfc6962
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.9
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Topic :: Security :: Cryptography
+Requires-Python: >=3.9
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: cryptography>=42
+Provides-Extra: sdjwt
+Provides-Extra: dev
+Requires-Dist: pytest>=7; extra == "dev"
+Requires-Dist: ruff>=0.5; extra == "dev"
+Requires-Dist: jsonschema>=4; extra == "dev"
+Requires-Dist: mypy>=1.8; extra == "dev"
+Requires-Dist: build>=1; extra == "dev"
+Requires-Dist: hypothesis>=6; extra == "dev"
+Dynamic: license-file
+
+<div align="center">
+
+<picture>
+  <source media="(prefers-color-scheme: dark)" srcset="assets/b7n0de-logo-dark.svg">
+  <img alt="b7n0de, Verified AI Work" src="assets/b7n0de-logo.svg" height="60">
+</picture>
+
+<h1>proofbundle</h1>
+
+**Emit and verify, fully offline, portable evidence that a piece of data was
+signed and anchored in a tamper-evident log — and optionally carries a
+selectively disclosable credential. Pure Python, no server, no daemon, one JSON file.**
+
+[![CI](https://github.com/b7n0de/proofbundle/actions/workflows/ci.yml/badge.svg)](https://github.com/b7n0de/proofbundle/actions/workflows/ci.yml)
+[![PyPI](https://img.shields.io/pypi/v/proofbundle.svg?color=D6248A)](https://pypi.org/project/proofbundle/)
+[![Python](https://img.shields.io/pypi/pyversions/proofbundle.svg?color=D6248A)](https://pypi.org/project/proofbundle/)
+[![License: MIT](https://img.shields.io/badge/license-MIT-D6248A.svg)](LICENSE)
+[![Ruff](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/ruff/main/assets/badge/v2.json)](https://github.com/astral-sh/ruff)
+[![SLSA build provenance](https://img.shields.io/badge/SLSA-build_provenance-D6248A.svg)](https://slsa.dev)
+
+</div>
+
+**At a glance:** `proofbundle emit` signs and anchors a payload; `proofbundle
+verify` checks one self-contained `bundle.json` with three offline cryptographic
+checks → `OK` or `FAILED`. No network, no daemon, no own crypto. 25 tests.
+
+## Contents
+
+- [Why](#why)
+- [What it verifies](#what-it-verifies)
+- [How it fits together](#how-it-fits-together)
+- [Install](#install)
+- [Quickstart](#quickstart)
+- [Interoperability](#interoperability)
+- [Bundle format](#bundle-format-proofbundlev01)
+- [Security notes and scope](#security-notes-and-scope-stated-honestly)
+- [Roadmap](#roadmap)
+- [Contributing](#contributing)
+- [License](#license)
+
+## Why
+
+Cryptographic evidence today usually needs a running service to check it.
+Sigstore Rekor, Certificate Transparency and other transparency logs are
+excellent, but verifying an inclusion proof normally means talking to a log
+server or wiring up Go tooling. There is no small, portable, Python-native
+verifier that takes one self-contained file and answers a simple question
+offline:
+
+*Were these exact bytes signed by this key, and anchored under this Merkle root,
+yes or no.*
+
+`proofbundle` is that verifier — and, since v0.2, the matching emitter. It is
+the verification half of a larger idea: turning a reproducible result (for
+example an AI evaluation run) into a signed, third-party-verifiable, selectively
+disclosable receipt. The verifier shipped first, small and correct, so it could
+be reviewed and trusted on its own; `emit_bundle` now creates bundles that
+`verify_bundle` accepts, fully offline on both sides.
+
+## What it verifies
+
+A bundle is a single JSON document. `proofbundle` checks, offline:
+
+1. **ed25519-signature** — the payload was signed by the stated Ed25519 key
+2. **merkle-inclusion** — the payload is anchored under the stated tree root,
+   using an RFC 6962 / RFC 9162 inclusion proof (the same primitive as Rekor and
+   Certificate Transparency)
+3. **sd-jwt** (optional) — an embedded SD-JWT selective-disclosure credential is
+   well formed, and if an issuer key is given, correctly issuer-signed
+
+The verifier treats the payload as opaque bytes. It proves that these exact
+bytes were signed and anchored, not what they mean. That is on purpose: it keeps
+the trusted core tiny.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+    P["payload bytes"]
+    P -->|"Ed25519 sign"| S["signature"]
+    P -->|"RFC 6962 anchor"| M["Merkle inclusion proof"]
+    SD["SD-JWT VC (optional)"] -.-> B
+    S --> B["bundle.json"]
+    M --> B
+    B --> V{{"proofbundle verify"}}
+    V --> C1["ed25519-signature"]
+    V --> C2["merkle-inclusion"]
+    V --> C3["sd-jwt (optional)"]
+    C1 --> R{"all checks pass?"}
+    C2 --> R
+    C3 --> R
+    R -->|yes| OK(["=> OK &nbsp; exit 0"])
+    R -->|no| FAIL(["=> FAILED &nbsp; exit 1"])
+
+    style V fill:#D6248A,stroke:#D6248A,color:#fff
+    style OK fill:#D6248A,stroke:#D6248A,color:#fff
+    style FAIL fill:#ef4444,stroke:#ef4444,color:#fff
+```
+
+## Install
+
+```bash
+pip install proofbundle
+```
+
+Requires Python 3.9+ and [`cryptography`](https://cryptography.io). Signature
+math is delegated to `cryptography`; this project never rolls its own crypto.
+The Merkle and SD-JWT logic is pure standard library.
+
+SD-JWT support is an optional extra (it adds no runtime dependency beyond the
+core `cryptography`, so the trusted core stays lean):
+
+```bash
+pip install "proofbundle[sdjwt]"
+```
+
+## Quickstart
+
+```bash
+# generate a real example bundle with throwaway keys
+python examples/make_example.py
+
+# verify it
+proofbundle verify examples/example_bundle.json
+```
+
+<div align="center">
+<img src="assets/demo.svg" alt="proofbundle verify output: four PASS checks and OK" width="680">
+</div>
+
+Machine-readable output and a non-zero exit code on failure:
+
+```bash
+proofbundle verify --json bundle.json   # exit 0 = ok, 1 = failed, 2 = malformed
+```
+
+Emit a bundle of your own (v0.2): sign a payload with a fresh key and anchor it,
+then verify it anywhere, offline.
+
+```bash
+proofbundle emit --payload-file result.json --new-key signer.key --out bundle.json
+proofbundle verify bundle.json
+```
+
+Library use:
+
+```python
+from proofbundle import verify_bundle
+
+result = verify_bundle("bundle.json")
+print(result.ok)          # True / False
+for check in result.checks:
+    print(check.name, check.ok, check.detail)
+```
+
+Verify a consistency proof between two log states directly:
+
+```python
+from proofbundle import verify_consistency
+verify_consistency(first_size, second_size, proof, first_root, second_root)  # -> bool
+```
+
+## Interoperability
+
+proofbundle uses the same RFC 6962 / RFC 9162 Merkle primitive as
+[Sigstore Rekor](https://docs.sigstore.dev/) and Certificate Transparency, so its
+`verify_inclusion` checks a real proof from a live transparency log, not just its
+own bundles. [`examples/rekor_interop.py`](examples/rekor_interop.py) verifies a
+real Sigstore Rekor inclusion proof (a committed fixture, `logIndex` 25579 in a
+4.16-million-entry tree) **fully offline**, and documents the field mapping from
+the Rekor bundle and its C2SP `tlog-checkpoint` signed note to proofbundle's
+`merkle` object. Correctness is also checked against external RFC 6962 test
+vectors vendored from
+[transparency-dev/merkle](https://github.com/transparency-dev/merkle) (see
+`tests/fixtures/`), plus Hypothesis property tests.
+
+## Bundle format (`proofbundle/v0.1`)
+
+The format is specified normatively in [SPEC.md](SPEC.md) (fields, encodings,
+RFC 6962 hashing, verification order) with a machine-readable JSON Schema at
+[`schemas/proofbundle_v0_1.schema.json`](schemas/proofbundle_v0_1.schema.json).
+
+```json
+{
+  "schema": "proofbundle/v0.1",
+  "payload_b64": "<the exact bytes that were signed and anchored>",
+  "signature": { "alg": "ed25519", "public_key_b64": "...", "sig_b64": "..." },
+  "merkle": {
+    "hash_alg": "sha256-rfc6962",
+    "leaf_index": 1,
+    "tree_size": 4,
+    "inclusion_proof_b64": ["...", "..."],
+    "root_b64": "..."
+  },
+  "sd_jwt_vc": { "compact": "<sd-jwt>", "issuer_public_key_b64": "..." }
+}
+```
+
+`sd_jwt_vc` is optional. Base64 fields are standard base64; the SD-JWT compact
+string uses base64url as per the spec.
+
+## Security notes and scope, stated honestly
+
+This is v0.1. It does exactly what it says and no more:
+
+- Ed25519 signatures only, for both the payload and the optional SD-JWT issuer
+  signature.
+- SD-JWT: the SD-JWT core is now [RFC 9901](https://datatracker.ietf.org/doc/rfc9901/)
+  (Dec 2025); this verifies that every presented disclosure is committed in the
+  issuer-signed payload, and the issuer signature (EdDSA) if a key is supplied. It
+  does **not** verify a Key Binding JWT, an X.509 or trust-list chain, status
+  lists, or `vct` type metadata. **SD-JWT VC** (the credential-type profile) is
+  still an IETF draft ([draft-ietf-oauth-sd-jwt-vc](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/));
+  full VC conformance is on the roadmap.
+- The verifier does not fetch anything. Trust anchors (the signer key, the
+  expected root) are inputs you supply out of band.
+- No custom cryptography. Ed25519 comes from `cryptography`; Merkle hashing is
+  RFC 6962.
+
+If you find a correctness or security issue, please open an issue or see
+[SECURITY.md](SECURITY.md).
+
+## Roadmap
+
+- **v0.1** — the offline verifier plus a real example bundle.
+- **v0.2 (current release)** — the emitter: `emit_bundle` signs a payload with
+  Ed25519 and anchors it as the last leaf of an RFC 6962 Merkle tree, producing
+  a bundle that `verify_bundle` accepts. Available as `proofbundle emit`.
+- **v0.3** — an eval-receipt emitter: wrap one evaluation framework run
+  ([Inspect AI](https://github.com/UKGovernmentBEIS/inspect_ai),
+  [lm-evaluation-harness](https://github.com/EleutherAI/lm-evaluation-harness))
+  into a signed receipt whose payload is a minimal canonical claim, for example
+  `{"suite": "...", "threshold": 0.8, "passed": true}`, optionally wrapped as an
+  SD-JWT VC so a holder can disclose *passed above threshold* without revealing
+  the model, weights or dataset, and carrying a cluster-bootstrap confidence
+  interval, a multiple-testing correction and a preregistration hash.
+
+That last step is the point: today no widely used AI project turns a
+reproducible evaluation result into a signed, third-party-verifiable,
+selectively disclosable receipt. This repository is the trustworthy verification
+core that makes it possible.
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) and the
+[Code of Conduct](CODE_OF_CONDUCT.md). Good first issues are labeled
+[`good-first-issue`](https://github.com/b7n0de/proofbundle/labels/good-first-issue).
+The verifier core aims to stay small, dependency-light and correct.
+
+## License
+
+MIT, see [LICENSE](LICENSE).
+
+---
+
+<p align="center"><sub>proofbundle is part of <b>b7n0de</b>, Verified AI Work &middot; <a href="https://b7n0de.com">b7n0de.com</a></sub></p>

proofbundle-0.3.0/README.md

@@ -0,0 +1,256 @@
+<div align="center">
+
+<picture>
+  <source media="(prefers-color-scheme: dark)" srcset="assets/b7n0de-logo-dark.svg">
+  <img alt="b7n0de, Verified AI Work" src="assets/b7n0de-logo.svg" height="60">
+</picture>
+
+<h1>proofbundle</h1>
+
+**Emit and verify, fully offline, portable evidence that a piece of data was
+signed and anchored in a tamper-evident log — and optionally carries a
+selectively disclosable credential. Pure Python, no server, no daemon, one JSON file.**
+
+[![CI](https://github.com/b7n0de/proofbundle/actions/workflows/ci.yml/badge.svg)](https://github.com/b7n0de/proofbundle/actions/workflows/ci.yml)
+[![PyPI](https://img.shields.io/pypi/v/proofbundle.svg?color=D6248A)](https://pypi.org/project/proofbundle/)
+[![Python](https://img.shields.io/pypi/pyversions/proofbundle.svg?color=D6248A)](https://pypi.org/project/proofbundle/)
+[![License: MIT](https://img.shields.io/badge/license-MIT-D6248A.svg)](LICENSE)
+[![Ruff](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/ruff/main/assets/badge/v2.json)](https://github.com/astral-sh/ruff)
+[![SLSA build provenance](https://img.shields.io/badge/SLSA-build_provenance-D6248A.svg)](https://slsa.dev)
+
+</div>
+
+**At a glance:** `proofbundle emit` signs and anchors a payload; `proofbundle
+verify` checks one self-contained `bundle.json` with three offline cryptographic
+checks → `OK` or `FAILED`. No network, no daemon, no own crypto. 25 tests.
+
+## Contents
+
+- [Why](#why)
+- [What it verifies](#what-it-verifies)
+- [How it fits together](#how-it-fits-together)
+- [Install](#install)
+- [Quickstart](#quickstart)
+- [Interoperability](#interoperability)
+- [Bundle format](#bundle-format-proofbundlev01)
+- [Security notes and scope](#security-notes-and-scope-stated-honestly)
+- [Roadmap](#roadmap)
+- [Contributing](#contributing)
+- [License](#license)
+
+## Why
+
+Cryptographic evidence today usually needs a running service to check it.
+Sigstore Rekor, Certificate Transparency and other transparency logs are
+excellent, but verifying an inclusion proof normally means talking to a log
+server or wiring up Go tooling. There is no small, portable, Python-native
+verifier that takes one self-contained file and answers a simple question
+offline:
+
+*Were these exact bytes signed by this key, and anchored under this Merkle root,
+yes or no.*
+
+`proofbundle` is that verifier — and, since v0.2, the matching emitter. It is
+the verification half of a larger idea: turning a reproducible result (for
+example an AI evaluation run) into a signed, third-party-verifiable, selectively
+disclosable receipt. The verifier shipped first, small and correct, so it could
+be reviewed and trusted on its own; `emit_bundle` now creates bundles that
+`verify_bundle` accepts, fully offline on both sides.
+
+## What it verifies
+
+A bundle is a single JSON document. `proofbundle` checks, offline:
+
+1. **ed25519-signature** — the payload was signed by the stated Ed25519 key
+2. **merkle-inclusion** — the payload is anchored under the stated tree root,
+   using an RFC 6962 / RFC 9162 inclusion proof (the same primitive as Rekor and
+   Certificate Transparency)
+3. **sd-jwt** (optional) — an embedded SD-JWT selective-disclosure credential is
+   well formed, and if an issuer key is given, correctly issuer-signed
+
+The verifier treats the payload as opaque bytes. It proves that these exact
+bytes were signed and anchored, not what they mean. That is on purpose: it keeps
+the trusted core tiny.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+    P["payload bytes"]
+    P -->|"Ed25519 sign"| S["signature"]
+    P -->|"RFC 6962 anchor"| M["Merkle inclusion proof"]
+    SD["SD-JWT VC (optional)"] -.-> B
+    S --> B["bundle.json"]
+    M --> B
+    B --> V{{"proofbundle verify"}}
+    V --> C1["ed25519-signature"]
+    V --> C2["merkle-inclusion"]
+    V --> C3["sd-jwt (optional)"]
+    C1 --> R{"all checks pass?"}
+    C2 --> R
+    C3 --> R
+    R -->|yes| OK(["=> OK &nbsp; exit 0"])
+    R -->|no| FAIL(["=> FAILED &nbsp; exit 1"])
+
+    style V fill:#D6248A,stroke:#D6248A,color:#fff
+    style OK fill:#D6248A,stroke:#D6248A,color:#fff
+    style FAIL fill:#ef4444,stroke:#ef4444,color:#fff
+```
+
+## Install
+
+```bash
+pip install proofbundle
+```
+
+Requires Python 3.9+ and [`cryptography`](https://cryptography.io). Signature
+math is delegated to `cryptography`; this project never rolls its own crypto.
+The Merkle and SD-JWT logic is pure standard library.
+
+SD-JWT support is an optional extra (it adds no runtime dependency beyond the
+core `cryptography`, so the trusted core stays lean):
+
+```bash
+pip install "proofbundle[sdjwt]"
+```
+
+## Quickstart
+
+```bash
+# generate a real example bundle with throwaway keys
+python examples/make_example.py
+
+# verify it
+proofbundle verify examples/example_bundle.json
+```
+
+<div align="center">
+<img src="assets/demo.svg" alt="proofbundle verify output: four PASS checks and OK" width="680">
+</div>
+
+Machine-readable output and a non-zero exit code on failure:
+
+```bash
+proofbundle verify --json bundle.json   # exit 0 = ok, 1 = failed, 2 = malformed
+```
+
+Emit a bundle of your own (v0.2): sign a payload with a fresh key and anchor it,
+then verify it anywhere, offline.
+
+```bash
+proofbundle emit --payload-file result.json --new-key signer.key --out bundle.json
+proofbundle verify bundle.json
+```
+
+Library use:
+
+```python
+from proofbundle import verify_bundle
+
+result = verify_bundle("bundle.json")
+print(result.ok)          # True / False
+for check in result.checks:
+    print(check.name, check.ok, check.detail)
+```
+
+Verify a consistency proof between two log states directly:
+
+```python
+from proofbundle import verify_consistency
+verify_consistency(first_size, second_size, proof, first_root, second_root)  # -> bool
+```
+
+## Interoperability
+
+proofbundle uses the same RFC 6962 / RFC 9162 Merkle primitive as
+[Sigstore Rekor](https://docs.sigstore.dev/) and Certificate Transparency, so its
+`verify_inclusion` checks a real proof from a live transparency log, not just its
+own bundles. [`examples/rekor_interop.py`](examples/rekor_interop.py) verifies a
+real Sigstore Rekor inclusion proof (a committed fixture, `logIndex` 25579 in a
+4.16-million-entry tree) **fully offline**, and documents the field mapping from
+the Rekor bundle and its C2SP `tlog-checkpoint` signed note to proofbundle's
+`merkle` object. Correctness is also checked against external RFC 6962 test
+vectors vendored from
+[transparency-dev/merkle](https://github.com/transparency-dev/merkle) (see
+`tests/fixtures/`), plus Hypothesis property tests.
+
+## Bundle format (`proofbundle/v0.1`)
+
+The format is specified normatively in [SPEC.md](SPEC.md) (fields, encodings,
+RFC 6962 hashing, verification order) with a machine-readable JSON Schema at
+[`schemas/proofbundle_v0_1.schema.json`](schemas/proofbundle_v0_1.schema.json).
+
+```json
+{
+  "schema": "proofbundle/v0.1",
+  "payload_b64": "<the exact bytes that were signed and anchored>",
+  "signature": { "alg": "ed25519", "public_key_b64": "...", "sig_b64": "..." },
+  "merkle": {
+    "hash_alg": "sha256-rfc6962",
+    "leaf_index": 1,
+    "tree_size": 4,
+    "inclusion_proof_b64": ["...", "..."],
+    "root_b64": "..."
+  },
+  "sd_jwt_vc": { "compact": "<sd-jwt>", "issuer_public_key_b64": "..." }
+}
+```
+
+`sd_jwt_vc` is optional. Base64 fields are standard base64; the SD-JWT compact
+string uses base64url as per the spec.
+
+## Security notes and scope, stated honestly
+
+This is v0.1. It does exactly what it says and no more:
+
+- Ed25519 signatures only, for both the payload and the optional SD-JWT issuer
+  signature.
+- SD-JWT: the SD-JWT core is now [RFC 9901](https://datatracker.ietf.org/doc/rfc9901/)
+  (Dec 2025); this verifies that every presented disclosure is committed in the
+  issuer-signed payload, and the issuer signature (EdDSA) if a key is supplied. It
+  does **not** verify a Key Binding JWT, an X.509 or trust-list chain, status
+  lists, or `vct` type metadata. **SD-JWT VC** (the credential-type profile) is
+  still an IETF draft ([draft-ietf-oauth-sd-jwt-vc](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/));
+  full VC conformance is on the roadmap.
+- The verifier does not fetch anything. Trust anchors (the signer key, the
+  expected root) are inputs you supply out of band.
+- No custom cryptography. Ed25519 comes from `cryptography`; Merkle hashing is
+  RFC 6962.
+
+If you find a correctness or security issue, please open an issue or see
+[SECURITY.md](SECURITY.md).
+
+## Roadmap
+
+- **v0.1** — the offline verifier plus a real example bundle.
+- **v0.2 (current release)** — the emitter: `emit_bundle` signs a payload with
+  Ed25519 and anchors it as the last leaf of an RFC 6962 Merkle tree, producing
+  a bundle that `verify_bundle` accepts. Available as `proofbundle emit`.
+- **v0.3** — an eval-receipt emitter: wrap one evaluation framework run
+  ([Inspect AI](https://github.com/UKGovernmentBEIS/inspect_ai),
+  [lm-evaluation-harness](https://github.com/EleutherAI/lm-evaluation-harness))
+  into a signed receipt whose payload is a minimal canonical claim, for example
+  `{"suite": "...", "threshold": 0.8, "passed": true}`, optionally wrapped as an
+  SD-JWT VC so a holder can disclose *passed above threshold* without revealing
+  the model, weights or dataset, and carrying a cluster-bootstrap confidence
+  interval, a multiple-testing correction and a preregistration hash.
+
+That last step is the point: today no widely used AI project turns a
+reproducible evaluation result into a signed, third-party-verifiable,
+selectively disclosable receipt. This repository is the trustworthy verification
+core that makes it possible.
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) and the
+[Code of Conduct](CODE_OF_CONDUCT.md). Good first issues are labeled
+[`good-first-issue`](https://github.com/b7n0de/proofbundle/labels/good-first-issue).
+The verifier core aims to stay small, dependency-light and correct.
+
+## License
+
+MIT, see [LICENSE](LICENSE).
+
+---
+
+<p align="center"><sub>proofbundle is part of <b>b7n0de</b>, Verified AI Work &middot; <a href="https://b7n0de.com">b7n0de.com</a></sub></p>

proofbundle-0.3.0/pyproject.toml

@@ -0,0 +1,67 @@
+[build-system]
+requires = ["setuptools>=68", "wheel"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "proofbundle"
+version = "0.3.0"
+description = "Emit and verify portable cryptographic evidence bundles, offline: Ed25519 + RFC 6962 Merkle + optional SD-JWT."
+readme = "README.md"
+requires-python = ">=3.9"
+license = { text = "MIT" }
+authors = [{ name = "Konrad Gruszka" }]
+keywords = [
+    "cryptography",
+    "merkle",
+    "transparency-log",
+    "ed25519",
+    "sd-jwt",
+    "verifiable-credentials",
+    "attestation",
+    "provenance",
+    "rfc6962",
+]
+classifiers = [
+    "Development Status :: 3 - Alpha",
+    "Intended Audience :: Developers",
+    "License :: OSI Approved :: MIT License",
+    "Programming Language :: Python :: 3",
+    "Programming Language :: Python :: 3.9",
+    "Programming Language :: Python :: 3.10",
+    "Programming Language :: Python :: 3.11",
+    "Programming Language :: Python :: 3.12",
+    "Topic :: Security :: Cryptography",
+]
+dependencies = ["cryptography>=42"]
+
+[project.optional-dependencies]
+# SD-JWT support is an optional capability. It adds NO runtime dependency beyond the core
+# `cryptography` (EdDSA + stdlib), so `pip install proofbundle[sdjwt]` keeps the trusted core
+# lean; the extra documents intent and is forward-compatible if SD-JWT ever needs a heavier lib.
+sdjwt = []
+dev = ["pytest>=7", "ruff>=0.5", "jsonschema>=4", "mypy>=1.8", "build>=1", "hypothesis>=6"]
+
+[project.urls]
+Homepage = "https://b7n0de.com"
+Repository = "https://github.com/b7n0de/proofbundle"
+Issues = "https://github.com/b7n0de/proofbundle/issues"
+Changelog = "https://github.com/b7n0de/proofbundle/blob/main/CHANGELOG.md"
+Documentation = "https://github.com/b7n0de/proofbundle#readme"
+
+[project.scripts]
+proofbundle = "proofbundle.cli:main"
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.setuptools.package-data]
+proofbundle = ["py.typed"]
+
+[tool.ruff]
+line-length = 100
+
+[tool.mypy]
+python_version = "3.10"
+files = ["src"]
+ignore_missing_imports = true
+warn_unused_ignores = true

proofbundle-0.3.0/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+

proofbundle-0.3.0/src/proofbundle/__init__.py

@@ -0,0 +1,30 @@
+"""proofbundle, an offline verifier for portable cryptographic evidence bundles.
+
+Verify, fully offline and in pure Python, that a payload was Ed25519 signed and
+anchored under an RFC 6962 Merkle root, with optional SD-JWT selective
+disclosure. The verification half of a signed, third-party-verifiable evidence
+receipt.
+"""
+
+from __future__ import annotations
+
+from .bundle import SCHEMA, load_bundle, verify_bundle
+from .emit import emit_bundle, generate_signer
+from .errors import Check, ProofBundleError, VerificationResult
+from .merkle import verify_consistency, verify_inclusion
+
+__version__ = "0.3.0"
+
+__all__ = [
+    "__version__",
+    "SCHEMA",
+    "verify_bundle",
+    "load_bundle",
+    "emit_bundle",
+    "generate_signer",
+    "verify_inclusion",
+    "verify_consistency",
+    "VerificationResult",
+    "Check",
+    "ProofBundleError",
+]