v0.2.0

Binaries

No Rust toolchain needed. Download the asset for your platform,
check it against sha256sums.txt, and run it. Linux builds are
static (musl); Windows ships verify.exe inside a .zip.

Platform	Asset
Linux x86_64	verify-v0.2.0-x86_64-unknown-linux-musl.tar.gz
Linux aarch64	verify-v0.2.0-aarch64-unknown-linux-musl.tar.gz
macOS Apple silicon	verify-v0.2.0-aarch64-apple-darwin.tar.gz
macOS Intel	verify-v0.2.0-x86_64-apple-darwin.tar.gz
Windows x86_64	verify-v0.2.0-x86_64-pc-windows-msvc.zip

$ sha256sum -c sha256sums.txt
$ tar -xzf verify-v0.2.0-x86_64-unknown-linux-musl.tar.gz
$ ./verify-v0.2.0-x86_64-unknown-linux-musl/verify ./CASE-2026-1842

Added

• Notary proof verification: verify now re-checks the signed record slice
  instead of only requiring it to be present. notary/pubkey.json must
  parse to a 32-byte Ed25519 key whose derived key id matches; every record
  must carry v: 1, that key id, and a valid Ed25519 signature over the
  canonical record with sig removed; seq must be continuous per camera
  and each prev_record_hash must link to its predecessor. A slice may
  begin mid-chain: the first record's earlier link is not claimed.
• Coverage: every retrieved[].source_sha256 must be present and covered by
  a signed segment record; provenance.detail counts, seq bounds, key id
  and camera must agree with the slice when present.
• BundleReport.notary_records (CLI --json: notary_records) reports how
  many signed records were verified.
• Negative vectors tampered-notary-signature and tampered-notary-chain,
  re-sealed so the failure lands inside the proof, plus a mid-chain unit
  test signed with the published test-vector seed.

Changed

• verify names the signed-record count for notary provenance.
• Dependencies: base64 and ed25519-dalek (verification only; no network
  capability, guarded by the existing Cargo.lock test).

Spec

• docs/SPEC.md §5.5 step 8 now specifies the signature, key-id, chain and
  coverage checks; §5.6 states what a bundled key does and does not prove;
  §7 allows verifier strictness to increase in a MINOR release for bundles
  that never conformed.

v0.1.0

Binaries

No Rust toolchain needed. Download the asset for your platform,
check it against sha256sums.txt, and run it. Linux builds are
static (musl); Windows ships verify.exe inside a .zip.

Platform	Asset
Linux x86_64	verify-v0.1.0-x86_64-unknown-linux-musl.tar.gz
Linux aarch64	verify-v0.1.0-aarch64-unknown-linux-musl.tar.gz
macOS Apple silicon	verify-v0.1.0-aarch64-apple-darwin.tar.gz
macOS Intel	verify-v0.1.0-x86_64-apple-darwin.tar.gz
Windows x86_64	verify-v0.1.0-x86_64-pc-windows-msvc.zip

$ sha256sum -c sha256sums.txt
$ tar -xzf verify-v0.1.0-x86_64-unknown-linux-musl.tar.gz
$ ./verify-v0.1.0-x86_64-unknown-linux-musl/verify ./CASE-2026-1842

Born public, born tagged.

Added

• Normative specification, schema v1: bundle layout, SHA256SUMS seal
  algorithm with metadata sidecar and bundle_hash promise, provenance
  proof rules (notary, disk_image), the post-seal allowlist, symlink
  prohibition, and the additive-only versioning policy.
• verify CLI and library: hash-only verification with streamed file
  hashing, set parity between manifest and disk, tamper rejection naming
  the file, and the exit contract (0 verified, 2 rejected, 3 usage).
• Canonical fixture set: minimal-full-coverage, coverage-gaps,
  notary-provenance, disk-image-provenance, and the negative
  tampered-original vector.
• CI: test, clippy -D warnings, the fixture gate, and a no-network crate
  guard over Cargo.lock.