73238135d6
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 |
||
|---|---|---|
| .. | ||
| burn_tests | ||
| click_tests | ||
| device_tests | ||
| emulators | ||
| fido_tests | ||
| persistence_tests | ||
| txcache | ||
| ui_tests | ||
| upgrade_tests | ||
| __init__.py | ||
| .gitignore | ||
| bip32.py | ||
| buttons.py | ||
| common.py | ||
| conftest.py | ||
| device_handler.py | ||
| download_emulators.sh | ||
| emulators.py | ||
| README.md | ||
| REGISTERED_MARKERS | ||
| show_results.py | ||
| tx_cache.py | ||
Tests
Burn tests
These tests are doing a simple read/write operations on the device to see if the hardware can endure high number of flash writes. Meant to be run on the device directly for a long period of time.
Device tests
Device tests are integration tests that can be run against either emulator or on an actual device. You are responsible to provide either an emulator or a device with Debug mode present.
Device tests
The original version of device tests. These tests can be run against both Model One and Model T.
See device-tests.md for instructions how to run it.
UI tests
UI tests use device tests and take screenshots of every screen change and compare them against fixtures. Currently for model T only.
See ui-tests.md for more info.
Click tests
Click tests are a next-generation of the Device tests. The tests are quite similar, but they are capable of imitating user's interaction with the screen.
Fido tests
Implement U2F/FIDO2 tests.
Upgrade tests
These tests test upgrade from one firmware version to another. They initialize an emulator on some specific version and then pass its storage to another version to see if the firmware operates as expected. They use fixtures from https://firmware.corp.sldev.cz/upgrade_tests/ which can be downloaded using the download_emulators.sh script.
See the upgrade-tests.md for instructions how to run it.
Persistence tests
These tests test the Persistence mode, which is currently used in the device recovery. These tests launch the emulator themselves and they are capable of restarting or stopping it simulating user's plugging in or plugging out the device.