trace-verify 0.3.0

The published 0.2.0 verifies non-ASCII records against bytes the producer never signed

canonical_body_bytes built the signature pre-image with json.dumps(sort_keys=True, ensure_ascii=True), while agentrust_trace.sign_record signs through rfc8785.dumps. The two agree on ASCII and diverge everywhere else, so signer and verifier computed different bytes for any record carrying an accented character, a non-Latin script, or an emoji.

old: b'{"note":"café","producer":"acme/1.0.0"}'
new: b'{"note":"caf\xc3\xa9","producer":"acme/1.0.0"}'

The failure mode is rejection, not acceptance

A verifier that reconstructs different bytes fails the signature check. 0.2.0 therefore rejected valid records; it did not accept invalid ones. Nothing was forgeable through this and no advisory is warranted.

It was still wrong in the one function whose entire job is reproducing what a producer signed.

Why 0.3.0 and not 0.2.1

The behaviour changed, not only the bytes. Signature verification now refuses rather than guessing when rfc8785 is unavailable:

pip install "trace-verify[signature]"

Falling back to a canonicalization that only agrees on ASCII is precisely how this defect shipped, so the fallback is gone and the error names what to install.

Scope is one function, deliberately

Four other json.dumps(sort_keys=True, ...) sites in this repository are correct. The anchor leaf is defined as sorted-key JSON by docs/anchor-format.md §1 and must not move. Two canonicalizations at two layers is the trap that document's §0 exists to name, and fixing the wrong one would have created the exact bug it warns about.

Reported externally as agentrust-io/trace-spec#138.