test: two expectations that pinned firmware defects (Hive wire symbol, 1-bit frame hash) - #223
Merged
BitHighlander merged 5 commits intoSep 14, 2026
Conversation
…lay name Two assertions read the asset symbol out of the transaction the DEVICE serialized and expected "HIVE". This file already knows better: _WIRE_SYMBOL at the top records that the 2020 rebrand renamed the tokens but not their on-chain serialization, and every operation this file builds itself is assembled with "STEEM"/"SBD" (confirmed against condenser_api.get_transaction_hex). So these two assertions were pinning the firmware's own mistake: it wrote "HIVE" where hived writes "STEEM", and the test agreed with it. The firmware side is fixed on the 7.15 line; this makes the expectation match the chain.
BitHighlander
added a commit
to BitHighlander/keepkey-firmware
that referenced
this pull request
Sep 12, 2026
The integration suite asserted the asset symbol the firmware used to write
("HIVE") rather than the one hived writes ("STEEM"), so it went red on the
serializer fix. keepkey/python-keepkey#223 corrects the two assertions against
the file's own _WIRE_SYMBOL table; pin it until that merges into the canonical
reconcile/upstream-sync branch, then re-pin there.
kkemu_get_display() lit every nonzero shade while the DebugLink layout and the capture ring used ordered dithering (display_mono_pixel_is_lit), so the dylib transport this test reads produced a different frame than the device's other evidence paths for the same screen -- and this golden pinned the odd one out. The firmware side is aligned on the 7.15 line; this is the frame all three serialisers now agree on.
BitHighlander
changed the title
BitHighlander
added a commit
to BitHighlander/keepkey-firmware
that referenced
this pull request
Sep 12, 2026
Second commit on keepkey/python-keepkey#223: the dylib transport's OLED frame hash, which pinned the pre-alignment 1-bit serialiser.
ci: test Python harness against current firmware audit heads
Contributor
Author
|
CI ref repair #224 is merged at |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two test expectations that pinned firmware defects rather than the chain/device behaviour, both surfaced while auditing the 7.15 release candidate.
1. Hive asset symbol. Two assertions read the asset symbol out of the transaction the device serialized and expected
"HIVE". This file already records the opposite at the top —_WIRE_SYMBOL = {"HIVE": "STEEM", "HBD": "SBD"}, confirmed againstcondenser_api.get_transaction_hex— and every operation it builds itself uses the wire spelling. The firmware wroteHIVEwhere hived writesSTEEM, and the test agreed with it. Firmware fixed on the 7.15 line, whose native goldens (captured from hived) already carried03 "STEEM".2. OLED frame hash.
kkemu_get_display()treated every nonzero shade as lit, while the DebugLink layout and the capture ring used ordered dithering (display_mono_pixel_is_lit) — so the dylib transport produced a different frame than the device's other evidence paths for the same screen, and this golden pinned the odd one out. Firmware aligned; this is the frame all three serialisers now agree on.