Based on original contribution by Max Kupriianov <xlab@hey.com>
Implemented EIP-712 typed data signatures in Ethereum app.
Add eth_abi into pyproject deps
device test for EIP 712
fixed hex decoding for address
fixup! fixed hex decoding for address
code quality, more pythonic code, removing unused imports
running black and isort on changed files
trezorctl file input for EIP 712 data signing
fixup! code quality, more pythonic code, removing unused imports
fixup! fixup! code quality, more pythonic code, removing unused imports
necessary changes after rebase to master
unit tests for sign_typed_data.py
new protobuf messages, working for nonarray types
simplified and verified solution for our simple data
support for simple arrays, without their confirmation
reverting protobuf value messages to bytes, appropriate changes
showing arrays in Trezor, code quality improvements
data validation on Trezor, minor improvements
using custom types for storing type data instead of dicts, addressing feedback from review
moving helper functions to its own file, tests for decode_data
additional overall tests
support for arrays of structs
adding support for metamask_v4_compat variable
using HashWriter object to collect the final hash continously
minor improvements in code quality
validate_field_type function
streaming values from client without saving them, missing UI
prototype of streamed UI using confirm_properties
accounting for bytes in data, more data types in integration tests
rebase on master, using f-strings
minor fixes and improvements from code review
StructHasher class for the whole hashing process
mypy and style changes
asking users whether to show structs and arrays
protobuf descriptions to fix make defs_check
unifying comments, mypy fix
unit tests for StructHasher class
UI fixtures, skipping device tests for T1
addressing majority of code review comments about code quality and structure
changing file structure - layouts, helpers, sign_typed_data
decode_data renaming and docstring, renaming unit test file
using tuples instead of lists in elifs
layout improvements
excluding core/src/apps/common/confirm.py file from the PR
True/False returning layout with Show more button
code review layout improvements
forgotten br_type argument to should_show_more
BREAKING CHANGE: StellarAssetType is renamed to StellarAsset.
The name StellarAssetType is reused for the corresponding enum.
Enums are introduced in several other places. Their values correspond to
allowed values of (previously int) fields so this should not pose a
compatibility problem.
Many fields are now required. We believe that this should not pose a
compatibility problem, because all known interfaces to Stellar signing
actually accept Stellar XDR on input, whose required fields match the
protobuf schema.
Initial EIP1559 implementation
Fix a few small issues
Progress on Python lib implementation and firmware
Fix RLP length
Start fixing tests
Fix legacy transactions
Simplify API and logic
Add EIP1559 tests
Fix access list formatting
Fix UI visiblity issue
Fix commented out code
fix: correct linting issues
Fix access_list protobuf formatting
Remove unneeded code
Remove dead code
Check tx_type bounds for EIP 2718
Reduce code duplication
Prefer eip2718_type over re-using tx_type
Add more tests
Simplify format_access_list
Simplify sign_tx slightly
Change Access List format and add logic to encode it
Fix a bunch of small PR comments
Fix a linting issue
Move tests out of class and regenerate
Remove copy-pasted comments
Add access list to CLI
Simplify _parse_access_list_item
Fix small mistakes following rebase
Fix linting
Refactor to use a separate message for EIP 1559 tx
Simplify changed legacy code
Fix a few small PR comments
Fix linting
fix(legacy): recognize SignTxEIP1559 on legacy build
Fix PR comments
This is what the spec recommends and it has been the case before
workflow-restarts, when `apps.webauthn.fido2` was imported exactly once
per lifetime.
With workflow-restarts, `fido2` is being imported repeatedly and the
keys regenerated. This does not seem to be a problem per the spec -- a
FIDO workflow will retain the same keys, and non-FIDO workflows can be
seen as unplugs/replugs as far as the FIDO functionality is concerned.
However, regenerating the keys is slow, which is a problem for the
hardware-based unit tests. We can avoid the slowness by returning to the
spec-mandated behavior and generating once per power-up.