test(7.15): hive signing suites (1614–1617) + clearsign v2 harness + chain test updates

[BitHighlander]

⚠️ Fix-before-merge / do-not-promote

device-protocol is pinned to a fork commit (7182973, BitHighlander) and .gitmodules points at BitHighlander/device-protocol. This does not satisfy the #36 → #111 → master → #196 promotion contract, and mirrors the gate upstream keepkey#196 already holds itself draft for.

The fork pin is currently unavoidable: the release protos (LoadClearsignSigner icon fields, Hive 1614–1617) exist on no canonical keepkey/device-protocol master commit until device-protocol#111 merges. The bindings here were regenerated from that pin.

Required before promoting keepkey#196 — once keepkey#111 lands on keepkey/device-protocol:master:

1. set .gitmodules url back to https://github.com/keepkey/device-protocol.git
2. pin the gitlink to the resulting canonical master commit
3. re-run docker_build_pb.sh, confirm bindings are byte-identical
4. only then undraft / promote

(The fork url in .gitmodules is pre-existing — set by e88ff15, already present at keepkey#196's head e728e311 — not introduced here. But this PR keeps it alive, so the gate applies.)

---

Stacks into reconcile/upstream-sync — the branch that PRs to master as keepkey#196. Per SOP the master merge becomes the canonical pin for firmware work, so the harness firmware runs against must ride it.

Companion to BitHighlander/device-protocol#36 (protos) and BitHighlander/keepkey-firmware#310 (icon hardening).

Why

Firmware fork develop pins python-keepkey 15d95ec; reconcile/upstream-sync was at e728e31 — 17 commits behind, leaving the merged Hive work with no upstream test coverage.

Review fixes applied

• Stale bindings — root cause: this repo's own device-protocol submodule was pinned at 2ec999a9, which lacks the icon fields and 1614–1617, so build_pb.sh regenerated from a protocol that never had them. Re-pinned + regenerated: LoadClearsignSigner now exposes icon/icon_width/icon_height/persist (constructing with icon= no longer raises ValueError); messages_pb2.py carries real 1614–1617 constants (mapping.py's manual table was masking their absence); client.load_clearsign_signer() accepts icon/dims/persist.
• Icon RLE reference decoder — now mirrors firmware exactly, including rejecting 0x80 (n = −128), which it previously accepted and thereby masked a real incompatibility. Golden vector + RUN/LITERAL + boundary/reject tests.
• Maya signature verification — both EVM tests now recover the signer from the EIP-155 sighash and assert it equals the device's own address, replacing the len(r)==32 structural asserts (which predate 560b897). Verified offline: tampered calldata does not recover to the signer.

Offline suites: 30 passed.

[BitHighlander]

Thanks — all three findings confirmed and fixed in a322ef1.

#2 (Medium) — incomplete bindings. Root cause found: this repo's own device-protocol submodule was pinned at 2ec999a9 — the same stale commit that lacks the icon fields and 1614–1617 — so build_pb.sh was regenerating from a protocol that never had them. Bumped the pin to f7b4580 and regenerated:

• messages_ethereum_pb2.py: LoadClearsignSigner now exposes icon, icon_width, icon_height, persist. Verified the exact symptom is gone — constructing with icon= no longer raises ValueError.
• messages_pb2.py: real MessageType_HiveSign{Message,Operations} / Signed{...} = 1614–1617 constants. You were right that mapping.py's manual table was masking the omission.
• client.load_clearsign_signer() now accepts icon/icon_width/icon_height/persist and documents the RLE contract (was RAM-only).
• New TestClearsignSignerIcon covers icon/dimensions/persist round-trip + text-only identities.

#1 (High) — icon wire contract. Fixed in device-protocol#36: the proto documented a packed 1bpp bitmap while firmware ran an RLE decoder. The RLE turned out to be load-bearing — a packed 1bpp 64×64 needs 512 bytes vs the 384-byte cap, so the documented format was impossible at the dimensions firmware accepts. The grammar + golden vector (03 FF FF 00 → FF FF FF 00) are now specified there and enforced here as a runnable test with a reference decoder traced from draw_bitmap_mono_rle().

#3 (Medium) — Maya tests didn't verify signatures. Correct, and worth noting the weakening predates 560b897 (its parent already had the structural asserts; the router change inherited them). Rather than re-freeze r/s, both sites now use recover_eth_signer(): rebuild the EIP-155 sighash from the exact tx fields, recover the signer from (v,r,s), assert it equals the device's own address for the path. Verified offline: a good signature recovers to the signer, and tampered calldata does not — so a wrong digest/calldata/key now fails, and the tests stay correct across future router changes.

Offline suites: 26 passed.

[BitHighlander]

All three confirmed. Fixed in 03af8d1; PR converted to draft with an explicit fix-before-merge gate.

Reference decoder masked the 0x80 incompatibility — correct, and the most important catch

My decoder accepted a 128-byte literal because Python ints don't overflow, hiding that firmware's int8_t counter cannot represent it. A reference decoder that accepts what the device cannot is worse than no reference at all. It now mirrors firmware exactly — rejects n == -128 and n == 0 — with the boundary tests you asked for: 0x80 rejected, -127/127 still decode. Contract fixed in device-protocol#36, firmware enforcement in keepkey-firmware#310 (which also rejects 0x80 in the decoder, since a proto comment can't bind a hostile host).

Fork pin — correct, and now gated

You're right that this doesn't satisfy #36 → #111 → master → #196, and that keepkey#196 holds itself draft for exactly this. Two notes:

• The fork url in .gitmodules is pre-existing (set by e88ff15, already present at test: firmware 7.x release test harness (hive, zcash, insight, thorchain denom, ripple memo) keepkey/python-keepkey#196's head e728e311) — but this PR keeps it alive, so the gate applies regardless.
• The fork pin is currently unavoidable: the release protos exist on no canonical keepkey/device-protocol master commit until minor fixups to work with firmware build keepkey/python-keepkey#111 merges, and the regenerated bindings have to come from somewhere.

So rather than pretend otherwise, #27 is now draft with a fix-before-merge section mirroring keepkey#196's, listing the required sequence: after keepkey#111 lands → url back to keepkey/device-protocol → pin the canonical master SHA → re-run docker_build_pb.sh → confirm bindings byte-identical → only then promote.

Re-pinned to 7182973 (the corrected contract) in the meantime; that change was comment-only upstream, so the regenerated bindings are byte-identical.

Offline suites: 30 passed.

[BitHighlander]

Fixed in 25df24c.

Reference decoder repeated the leniency — correct. It filled w*h and returned, so it accepted a straddling run (05ff at 2×2) and silently ignored trailing packets. Same class of bug as the 0x80 case: a reference that accepts what the device rejects hands client authors an encoder that produces invalid icons. It now mirrors firmware's draw_bitmap_mono_rle_valid() exactly — rejects leftover run counters and any unconsumed input — with straddling-run and trailing-packet tests added. Offline suites: 32 passed.

On the CircleCI finding (#3): this one is expected rather than a gap. python-keepkey's CircleCI can't clone fork branches, but these tests don't get their coverage there — they run in the firmware repo's CI (python-integration-tests / python-dylib-tests), which pins the pyk commit and runs the suite against the built firmware. That's the gate that matters for this stack, and it's green on BitHighlander/keepkey-firmware#310. Leaving the CircleCI config alone rather than changing shared CI for a fork-only workflow.

Firmware fixes for the icon findings: BitHighlander/keepkey-firmware#310 (full suite 262/262).

[BitHighlander]

All three points confirmed and fixed in c475482. Your pin finding was not academic — it was hiding a real breakage.

The pin waiver was wrong, and running rc10 against these pins proved it

You were right that firmware CI runs whatever firmware pins, so the last three commits had no coverage anywhere. We ran rc10 against these exact pins before upstreaming, and the Maya tests failed:

TypeError: assertEqual() takes 3 positional arguments but 4 were given
FAILED test_msg_mayachain_signtx.py::test_sign_eth_add_liquidity
FAILED test_msg_mayachain_signtx.py::test_sign_eth_btc_swap
=========== 2 failed, 544 passed ===========

common.KeepKeyTest overrides assertEqual with no msg parameter (commit 591dba8 fixed this exact trap once before). My failure message made it 4 args — so both tests errored and the signature verification never actually ran. The "Maya tests now verify signatures" claim was false at that pin. Fixed, and the bespoke helper is replaced with the one already proven in test_msg_ethereum_clear_signing.py (same signature, hashfunc=None).

Now: 546 passed, 0 failed. Firmware #310's pin is bumped to c475482 so CI runs it.

The contract was contradictory — fixed

client.py now says: literals [-127,-1], 0x80 invalid, width 1..40 (LEFT_MARGIN_WITH_ICON), height 1..64, plus the exactness rule (no straddling run, whole input consumed) and an accurate persist description.

The "64×64 can't fit" rationale is dead — you're right, and I've removed it

Once width was capped at 40, my own argument collapsed: a packed icon at the legal maximum is 40×64/8 = 320 bytes, which fits the 384-byte cap. The honest reason for RLE is that draw_bitmap_mono_rle() is the decoder of record and every bundled image already uses it — not that packed wouldn't fit. The test now asserts that instead of encoding dead arithmetic.

#36 gets the same treatment (stale arithmetic + the RAM-only line that contradicts persist) in the next push.