test(display): assert the screen distinguishes what the device signs

[BitHighlander]

Small, self-contained test-only PR. Intended to merge before #197, which is +10414/-1030 across 57 files — this is one new file and touches nothing existing, so it should not conflict with that reconcile either way.

What it adds

On-screen coverage for the display/sign divergences found in the firmware 7.14.2 audit, written as a single property rather than a list of known payloads:

Two requests whose signed bytes differ must not produce identical screens.

If two payloads render the same pixels, whatever separates them was invisible at the moment the user approved, and the signature covers the difference. That is the shape of every divergence the audit turned up — TON/TRON unbound fields, Cosmos IBC receiver, Osmosis denom, message truncation — independent of which chain or field carried it.

Why differential, and why pixels

DebugLinkState.layout is the framebuffer; there is no text channel. So the assertions compare screen sequences rather than strings.

That is a feature here. The tests assume nothing about wording, spacing, fonts, or which truncation strategy the firmware picks, so they keep holding when the copy changes — and they cannot be satisfied by a screen that merely looks plausible.

Each pair puts the difference exactly where an implementation stops looking:

Case	The trap
embedded NUL	a protobuf bytes field is not a C string; "%s" stops at the NUL, the signature does not
whitespace padding	a leading space costs zero pixels once wrapped, so a padded body can measure as fitting
past one screenful	a truncating renderer drops the tail rather than paging it
newline padding	exercises the row counter rather than the character count

Refusal counts as a pass. A device that declines to sign what it cannot display honestly has satisfied the property. The failure under test is signing it while showing the user something indistinguishable from the benign case.

Two details worth review

• It builds the SignMessage protobuf directly instead of calling client.sign_message(). That helper applies normalize_nfc() and re-encodes to UTF-8, which would rewrite the very payloads under test — a NUL-bearing or whitespace-padded body would not survive it intact. A hostile host has no such helper in the way, so the test should not either.
• There is a guard test. Every other assertion compares screen sequences, so a flow producing no ButtonRequest would make two payloads compare equal as empty tuples and pass vacuously. One case asserts at least one non-blank screen is actually shown.

Firmware gating

Gated to >= 7.14.2 via requires_firmware. On older firmware these payloads are signed with a truncated or NUL-stopped display — that is the defect — so without the gate they would fail against firmware that predates the fixes. They skip instead, which means this is safe to merge now and activates when 7.14.2 firmware is present.

Verification status — please read before merging

Syntax-checked and logic-reviewed; not yet executed against a 7.14.2 emulator. Running them needs the dylib transport (KK_TRANSPORT=dylib) against an emulator built from firmware release/7.14.2, which is not yet cut. Until then they skip.

I would rather say that plainly than imply a green run I have not produced. If you would like, I can wire the emulator build and post an actual run before this merges.

[BitHighlander]

Pushed two follow-ups so these tests feed the report pipeline instead of only running.

Renamed the module to test_msg_display_disclosure.py.parse_junit() only derives a module key for files matching test_msg_ / test_sign_ / test_verify_. Under the old name the results keyed on the bare method name, which can collide with another suite's test of the same name and silently attribute the wrong status. The prefix is load-bearing, not cosmetic.

Added SECTIONS group D at min version 7.14.2, one entry per case with screenshot expectations. SECTIONS drives --screenshot-filter, so Phase 1 of scripts/emulator/python-keepkey-tests.sh now captures the actual OLED frames for each payload pair. That turns "the screens differ" from an assertion into visual evidence attached to the build — which is most of what an on-device OLED review round is for, without needing the device.

Verified both directions rather than assuming:

--fw-version=7.14.1 -> section D included: False
--fw-version=7.14.2 -> section D included: True

So this stays inert against released firmware and activates when 7.14.2 is present.

How it gets exercised

BitHighlander/keepkey-firmware@release/7.14.2 now pins deps/python-keepkey at 81e581f. The firmware CI derives FW_VERSION from CMakeLists.txt (7.14.2 on that branch), so requires_firmware passes there and the tests run rather than skip. Phase 2's pytest exit code is the CI gate, so a display/sign divergence fails the build.

That pin is temporary and points at this branch. Once this merges, the firmware repins to master — otherwise the release ships pinned to a branch commit.

Still not executed

I have not run these against a 7.14.2 emulator; that build is not cut yet. I would rather say so than imply a green run. The first execution may well fail on harness details — the callback_ButtonRequest override or device setup in the base fixture — and if it does I will fix it rather than weaken the assertions.