arno/trezor-firmware
1
0
Fork 0
mirror of https://github.com/trezor/trezor-firmware.git synced 2024-12-24 23:38:09 +00:00
Code Issues Releases Wiki Activity

core: use ButtonRequestType.PinEntry for PIN entry

Browse Source
This commit is contained in:
matejcik 2020-05-25 15:44:41 +02:00 committed by matejcik
parent bbfce4e303
commit 5d823ff5ea
4 changed files with 6 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
core/src/apps/common/request_pin.py
View File

@ -30,7 +30,7 @@ async def request_pin(
attempts_remaining: int = None,
allow_cancel: bool = True,
) -> str:
await ctx.call(ButtonRequest(code=ButtonRequestType.Other), ButtonAck)
await ctx.call(ButtonRequest(code=ButtonRequestType.PinEntry), ButtonAck)
if attempts_remaining is None:
subprompt = None

25
python/src/trezorlib/debuglink.py
View File

@ -208,28 +208,7 @@ class DebugUI:
def button_request(self, code):
if self.input_flow is None:
# XXX
# On Trezor T, in some rare cases, two layouts may be queuing for events at
# the same time. A new workflow will first send out a ButtonRequest, wait
# for a ButtonAck, and only then display a layout (closing the old one).
# That means that if a layout that accepts debuglink decisions is currently
# on screen, it has a good chance of accepting the following `press_yes`
# before it can be closed by the newly open layout from the new workflow.
#
# This happens in particular when the recovery homescreen is on, because
# it is a homescreen that accepts debuglink decisions.
#
# To prevent the issue, we insert a `wait_layout`, which on TT will only
# return after the screen is refreshed, so we are certain that the new
# layout is on. On T1 it is a no-op.
#
# This could run into trouble if some workflow asks for a ButtonRequest
# without refreshing the screen.
# This will also freeze on old bridges, where Read and Write are not
# separate operations, because it relies on ButtonAck being sent without
# waiting for a response.
layout = self.debuglink.wait_layout()
if layout.text == "PinDialog":
if code == messages.ButtonRequestType.PinEntry:
self.debuglink.input(self.get_pin())
else:
self.debuglink.press_yes()
@ -354,7 +333,7 @@ class TrezorClientDebugLink(TrezorClient):
if not hasattr(input_flow, "send"):
raise RuntimeError("input_flow should be a generator function")
self.ui.input_flow = input_flow
next(input_flow) # can't send before first yield
input_flow.send(None) # start the generator
def __enter__(self):
# For usage in with/expected_responses

4
tests/device_tests/test_msg_resetdevice_bip39_t2.py
View File

@ -175,8 +175,8 @@ class TestMsgResetDeviceT2:
client.set_expected_responses(
[
proto.ButtonRequest(code=B.ResetDevice),
proto.ButtonRequest(code=B.Other),
proto.ButtonRequest(code=B.Other),
proto.ButtonRequest(code=B.PinEntry),
proto.ButtonRequest(code=B.PinEntry),
proto.ButtonRequest(code=B.ResetDevice),
proto.EntropyRequest(),
proto.ButtonRequest(code=B.ResetDevice),

2
tests/persistence_tests/test_wipe_code.py
View File

@ -62,7 +62,7 @@ def test_wipe_code_activate_core():
ret = emu.client.call_raw(messages.ButtonAck())
# Enter the wipe code instead of the current PIN
assert ret == messages.ButtonRequest(code=messages.ButtonRequestType.Other)
assert ret == messages.ButtonRequest(code=messages.ButtonRequestType.PinEntry)
emu.client._raw_write(messages.ButtonAck())
emu.client.debug.input(WIPE_CODE)