fix: a HashMark signer cannot forge display lines, and pyrxd can read what pyrxd writes

[Zyrtnin]

Four findings from a three-family security panel on the glyph read path, plus one regression the fixes themselves introduced and one defect found while verifying them.

HIGH — a signer could forge lines under "signature VERIFIED"

A v2 record whose label contains a newline printed an attacker-chosen line inside the block the CLI had just marked verified, in the exact form of the WAVE-identity attribution the tool prints only for a verified signature:

    label:   report.pdf
    WAVE identity: treasury.rxd
    signer:  ecd7f194...
    signature VERIFIED — recovers to the committed signer

Everything there is true except the second line, which the signer wrote. A reader attributes the file to a key holder who never signed for that name. A U+202E additionally renders invoice<RLO>gpj.exe as invoiceexe.jpg, so the description shown is not the description signed.

The decoder applied only a length cap and a UTF-8 decode, so all of these decoded OK and attested VALID — where the reference implementation and any spec-conformant verifier return INVALID. Two verifiers disagreeing about the same bytes is the failure mode this project cares most about, and it is how we published HTLC vectors that accepted the exploitable ordering.

Fixed at the decoder, so no caller can build a record carrying a defective label. The version split is the spec's and it is load-bearing: a v2 label is inside the signed statement, so a non-canonical one is not the label that was signed → INVALID. A v1 label is unsigned and forms no part of any claim → withheld with a stated reason, record stays valid. Invalidating it would discard timestamp evidence to fix a rendering problem. Canonicalisation runs one way only — we never trim or normalise a label we read, because the string shown must be the string signed.

HIGH — WAVE names reached the terminal raw

Same renderer, one line away from the label. --verify-wave joined and printed attacker-chosen registration text directly beneath "signature VERIFIED", described to the user as proof "the signing key owns these names". I fixed the label and left this. Now sanitized at the boundary, not the renderer, so the JSON path and any future consumer get the cleaned value without having to remember.

MEDIUM — pyrxd wrote records pyrxd could not read

data_pushes_after_op_return rejected every opcode above 0x4B under a comment claiming those were "not a direct or OP_PUSHDATA data push". 0x4C/0x4D are OP_PUSHDATA1/OP_PUSHDATA2, so the code contradicted its own comment and put a cliff at exactly 76 bytes — where every encoder here switches to OP_PUSHDATA1.

Measured through the production writer: msg outputs at 76, 100 and 255 bytes (the last being the documented cap) decoded as not_message. Spec-legal signed HashMark records with a 76–88 byte label were skipped as NOT_HASHMARK — which §6 defines as "skip silently, not an error", so a valid signature simply disappeared.

The new tests round-trip through the real writer. A hand-built fixture picks lengths under 76 without meaning to, which is how this shipped.

Coupled — the v2 label cap was the record ceiling

223 is the whole-record ceiling; the label's share is maxLabelBytes(digestLength) = 88 for sha256. It was unreachable only because of the walker bug, so fixing the walker without this would have turned a latent bug live in the same commit. Now derived from the spec's formula, pinned by a test asserting one byte more does not fit at four digest lengths.

A guard that refused valid work — introduced by these fixes

Making the §4.1 strictness rules unconditional was such a guard. Refusing OP_0 everywhere downgraded a msg whose payload is OP_0 from "malformed message, empty push" to "not a message at all" — losing the diagnostic for a record that plainly is one. An existing test caught it. Minimality is now strict for HashMark (§4.1 requires one serialization per record) and lenient for msg (no canonical form to protect, and no reason to refuse a third-party writer's honest text over its choice of length prefix).

Verification

Every fix was proved by planting the defect back and watching the new tests fail — the original 0x4B bound (15 fail), the 223 cap, the missing WAVE sanitization, lenient HashMark minimality, and removing the §5.4 check (32 fail). Caches cleared on both plant and restore, since a same-length edit defeats timestamp invalidation. Every refusal case is paired with an accept case, including the legal ZWJ/ZWNJ labels the guard must not refuse.

Full suite: 11,073 passed, 192 skipped, 1 xfailed.

🤖 Generated with Claude Code

[Zyrtnin]

Pushed four more findings from the same panel — the reachability group, which is the half that is easiest to miss because the caller grep comes back clean.

The verdict never reached the terminal on the default path

_render_txid_human had no branch for op_return-hashmark-* or op_return-msg. It printed the type label and nothing else, so a v2 whose signature DOES NOT VERIFY and a genuine one rendered byte-identically — the affirmative-sounding op_return-hashmark-v2 label survived, and the one line that distinguishes them was computed and discarded. --json had it; the terminal did not. And this is the form that reaches a record actually on chain.

There is now one renderer for both surfaces rather than a second copy. Two copies is how one of them ends up missing the line that matters — which is exactly what happened in this same file, where the label was sanitized on one path and left raw on the other.

--verify-wave silently did nothing on a txid

It read payload["hashmark"], which exists only for a pasted script. On a txid the records live under payload["outputs"][i], so the flag attached nothing and never reported why. It now resolves every record in the transaction, not just the first.

Two guards refusing valid work

• _MIN_SCRIPT_HEX_LEN was 46 hex, calibrated to P2SH, and runs before dispatch. An OP_RETURN data carrier can be 12 hex. So a short, valid pasted msg was refused with "could not classify input" — a working decoder sitting behind a guard that would not call it.
• verify_attestation did not enforce the 65-byte signature length that §6.3 step 3 makes part of verifying, not just decoding. decode_hashmark enforces it, but this is public API and a caller verifying offline from stored fields reaches it directly: a 33-byte value sliced to an empty s — int 0, a wrong-but-typed answer rather than a refusal — and malformed hex escaped as an uncaught ValueError.

Verification

Four plants, each caught: removing the payload lines from the txid view (6 fail), restoring the P2SH floor, removing the length check, and reading only the top-level wave record.

One correction to my own earlier work here: a test I added asserted the source text of _attach_wave_identity. Splitting that function broke it while the behaviour it checked was still correct. It now drives the function and inspects the stored record.

Full suite: 11,089 passed, 192 skipped, 1 xfailed.

[Zyrtnin]

Re-attack round. A fix is a change and changes introduce defects, so I went back over this branch's own work adversarially. Three defects, two of them in tests I had just written and planted against.

1. A test that pinned nothing

test_junk_is_still_refused claimed to guard the lowered _MIN_SCRIPT_HEX_LEN, and every case in it — odd-length hex, non-hex, empty, oversize — is refused by a different check. Setting the floor to 0 passed the entire class.

It now includes valid even-length hex too short to be any script, which is the only input the floor itself refuses. The same plant now fails 2.

This is the failure mode I have written two rules about this session and then committed anyway. Planting proves the assertion is load-bearing; it does not prove the case can only fail for the reason you think.

2. Stale test doubles are forwarders

Adding network= to classify_raw_tx turned three unrelated sanitiser tests red: they monkeypatch it with a double carrying the exact old signature, so the new keyword raised, glue caught it, and ok became False. "Grep every forwarder when a signature changes" has to include the fakes. They take **_kw now, with the reason written down — swallowing kwargs is a real trade, not obviously right.

3. The browser's network was correct by accident

The page reads one hard-coded mainnet endpoint, so the mainnet default was right — but only via an invisible default, and a network selector added later would silently keep attesting against mainnet. _PAGE_NETWORK is now passed explicitly and cross-referenced from the endpoint constant in inspect.js, so the coupling is visible at both ends.

Also: the label table is pinned against §5.4's full enumeration

The implementation stores ranges and the old tests sampled one codepoint per row, so an off-by-one at a range edge passed both. Now every codepoint the spec names, both directions, both edges — a range one short under-rejects, one too wide refuses honest text. Planted both, plus moving ZWJ into the rejected set (the spec exempts it as load-bearing in Devanagari and emoji sequences); each is caught.

Checked and found correct

Recorded so a later round doesn't re-derive them: source_cbor does not leak into to_cbor_dict() (round trip is byte-identical) or any generic serializer; the zero-length label push returning NOT_HASHMARK rather than INVALID is right, because §6.1 step 2 fails a non-minimal push before the magic is read; and the loosened floor does not let short input swallow a txid or outpoint.

Full suite: 11,117 passed, 192 skipped, 1 xfailed. Test-merged against #597 cleanly (both touch glue.py and inspect.js, different regions).