trace-verify 0.4.0

One install now answers all three questions a reader can ask of this registry.

pip install trace-verify

trace-verify --claim C.json --proof P.json --entry E.ndjson   # is my claim anchored?
trace-verify chain E.ndjson [MORE...]                          # does the registry's history hold?

pip install "trace-verify[witness]"
trace-verify receipt --checkpoint CP.json --response POST.json \
  --registry-key HEX --witness-key HEX --expected-log-id ID    # does an outside witness agree?

Chain verification was a Python API with no command, and witness-receipt verification was not in the package at all. Both were reachable only by cloning the repository.

verify_chain_against_entries is new in the package and is the substantive part. It rebuilds the Merkle Mountain Range from the raw entries and compares it to what each checkpoint claims, which is what catches a quiet edit to an already-anchored entry: such an edit leaves every checkpoint record's own math self-consistent, so the chain-consistency check still passes and only the recompute fails. That check previously existed in the repository and nowhere a pip user could reach it.

Compatibility. The inclusion check keeps its bare-flag form, so every invocation written against 0.3.x runs unchanged. Only the literal tokens chain and receipt route. cbor2 and scitt-cose are imported inside the witness verifier rather than at module scope, so import trace_verify still works without a CBOR stack; they arrive through the new witness extra.

--version was wrong before this. 0.3.0 and 0.3.1 both answered --version with 0.1.0. The publish workflow now refuses a release whose tag disagrees with the packaged version, or whose __version__ disagrees with pyproject.toml.

Package metadata. Homepage, Bug Tracker and Changelog point at this repository again, now that it is public. License metadata is Apache-2.0.

Full notes: CHANGELOG.md