chore(deps): repin python-keepkey dress rehearsal to #214 head - #483
Merged
Conversation
Dress-rehearsal pin moves 81e581f -> c75fbd5, the head of keepkey/python-keepkey #214, which is now the single open PR to master for this release. #215 was folded into #214 and closed. SOP is one release PR whose head is the pin; splitting the chain_id work into a second PR gave this release two candidate pins, which was my error. Nothing was lost -- the EIP-155 oracle, the regenerated golden vectors, the two refusal tests and the client fix all moved across unchanged. The branch was also 36 commits behind master, so it lacked 027146f ("test(0x): enable AdvancedMode for transformERC20 blind-sign") among others. Merged master up; no conflicts. Measured against this firmware on a clean emulator: before 22 failed, 362 passed, 47 skipped after 3 failed, 394 passed, 70 skipped The nineteen that cleared were the chain_id five, the fourteen policy-gate opt-ins, and transformERC20. The three that remain share one cause -- the device now shows more screens than the pinned test acknowledges: test_eos_signtx_updateauth paginated payload test_thorchain_sign_tx "Additional memo field" screens test_sign_with_thorchain_memo (Ripple) same memo disclosure, newly visible None is a firmware defect. Fixing them means teaching the tests the new button flow, never removing disclosure: those screens show affiliate-fee bytes that were previously signed invisibly.
Advance the dress-rehearsal pin from c75fbd5 to 6c4ad17, the current head of keepkey/python-keepkey#214. The additional commit re-gates the XRP THORChain memo test without weakening its assertion. The host-side memo transport gap is tracked separately as keepkey/keepkey-vault#422; firmware never receives the memo. With #482 plus this pin, the expected integration result is zero failures, with XRP memo support explicitly deferred rather than normalized as missing.
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.
What
Repin
deps/python-keepkeyfrom81e581fthrough the consolidated release work to6c4ad17, the current upstream head ofkeepkey/python-keepkey#214.This is a genuine upstream commit reachable from the
.gitmodulesURL; it is not a fork-only object.Why
The old pin predates the release-side expectation updates and host fixes. The consolidated #214 head includes:
chain_idexpectation/client fixes,The XRP test remains the intended target behavior and is skipped with a specific reason until memo support can actually traverse hdwallet ->
RippleSignTx; that host-side gap is tracked askeepkey/keepkey-vault#422.Measured result
Against the earlier consolidated head (
c75fbd5) on a clean emulator:22 failed, 362 passed, 47 skipped3 failed, 394 passed, 70 skippedNineteen failures cleared without weakening firmware disclosure.
The remaining two deadlocks are addressed independently by firmware PR #482, which restores the wire invariant that every required physical hold is announced with a
ButtonRequest. The third former failure is the XRP memo test, now explicitly deferred rather than rewritten to accept memo loss.With #482 plus this pin, the expected integration outcome is zero failures.
Release invariant
Tests adapt to newly required disclosure. Firmware disclosure is never removed to satisfy a stale test.