apps.webauthn.boot() does not need an if-condition because it's only
called from session.py when the usb interface is enabled
This means that they do not need to be stored in RAM at all. The obvious
drawback is that we need to hand-edit the if/elif sequence, but we don't
register new handlers all that often so 🤷
Layouts can be used by the application code to interact with user using
small number of dialogs or other groups of UI components. Each layout is
identified by name and takes some parameters. Most layouts will have an
implementation for each hardware model, mechanism is provided to import
the correct version so that application code can be oblivious to the
model.
This commit introduces the layout concept and converts a couple of
dialogs to use it.
They now live under trezor.ui.components.tt. Later
trezor.ui.components.t1 will be added and application code will be
rewritten to not use them directly in order to work on both TT and T1.
this makes sense, really: close_others() requests UI exclusivity, and
that is something that generally happens at the same places we emit a
ButtonRequest
The original wait_layout was unreliable, because there are no guarantees
re order of arrival of the respective events. Still, TT's event handling
is basically deterministic, so as long as the host sent its messages
close enough to each other, the order worked out.
This is no longer the case with the introduction of loop.spawn: TT's
behavior is still deterministic, but now ButtonAck is processed *before*
the corresponding wait_layout, so the waiting side waits forever.
In the new process, the host must first register to receive layout
events, and then receives all of them (so the number of calls to
wait_layout must match the number of layout changes).
DebugLinkWatchLayout message must be version-gated, because of an
unfortunate collection of bugs in previous versions wrt unknown message
handling; and this interests us because upgrade-tests are using
wait_layout feature.
this prevents a certain class of UI test failure. It also localizes the
use of debuglink signals into the layout classes instead of call sites,
which is a design we were already using for confirm_signals
Apart from making the code more correct for its users in
apps.common.confirm and elsewhere, this fixes a problem where the
confirm_signal would be scheduled before the dialog is rendered.
By making sure that handle_rendering is scheduled (i.e., listed in
create_tasks) before confirm_signal, we can be sure to render at least
once and thus appear in the UI test results.
This is to avoid including app-specific functionality in storage and
avoid circular imports. The following policy is now in effect: modules
from `storage` namespace must not import from `apps` namespace.
In most files, the change only involves changing import paths.
A minor refactor was needed in case of webauthn: basic get/set/delete
functionality was left in storage.webauthn, and more advanced logic on
top of it was moved to apps.webauthn.resident_credentials.
A significant refactor was needed for sd_salt, where application (and
UI) logic was tightly coupled with the IO code. This is now separated,
and storage.sd_salt deals exclusively with the IO side, while the app/UI
logic is implemented on top of it in apps.common.sd_salt and
apps.management.sd_protect.
all debug input signals are now channels, and DebugLinkDecision handler
waits until the input was consumed. This means that the input events are
queued; originally, if an input event arrived before the previous was
consumed, the previous input would be lost.
reset words and their positions are now also channels, and
DebugLinkGetState can wait for their updates, if required
