Trezor firmware

This commit adds metadata for a new Ethereum yield vault called 'Trezor Steakhouse ETH Prime Vault' so that Trezor devices can display a friendly name and token details when users interact with it. It is a product feature addition, not a security fix or vulnerability.

This commit only updates the project's cryptographic test suite to match a newer version of the Wycheproof test-vector submodule. It changes test data file names and field names (for example, 'keyDer' to 'publicKeyDer') and adds a safety check for empty padding data in a test helper. None of these changes affect the actual Trezor firmware code that users rely on for security.

This commit only adds and improves test code. It extends an existing test suite to check more cryptographic algorithms (AES-GCM, AES-CCM, HMAC, PBKDF2) using well-known public test vectors from Project Wycheproof. It also fixes a few small helper functions in the test file so they correctly report failures. There is no change to the actual Trezor firmware or its cryptographic library, so this commit does not introduce or fix a security vulnerability in the product itself.

This commit tightens validation in the hardware wallet's AES-GCM encryption code by rejecting initialization vectors (IVs) of length zero. Previously, a zero-length IV was silently accepted, which violates the NIST standard and can lead to weak or broken encryption. The change also makes the higher-level encrypt/decrypt functions properly report this error instead of ignoring it.

This commit only adds a new test to the Trezor firmware crypto test suite. It checks that multiplying certain special 'low-order' points on the Curve25519 curve by various secret scalars always produces an all-zero result. There is no change to the actual cryptographic code being tested, only a new regression test. By itself, this commit does not fix or introduce a security vulnerability.

This commit only adds new protocol buffer message definitions for an upcoming Ethereum feature (EIP-7702 authorization signing). It does not contain any actual signing logic, device firmware behavior, or user-interface code. It is a schema-only change and therefore does not introduce a security vulnerability by itself.

This is a code-style cleanup commit in the Trezor firmware's Rust code. It replaces plain `as` type casts with explicit conversion methods like `u32::from(...)`, `i16::from(...)`, and `f32::from(...)` to satisfy the Rust Clippy lint `cast_lossless`. These changes do not alter program behavior; they only make the code clearer and avoid compiler warnings. There is no security fix or functional change here.

This commit fixes a minor user-interface inconsistency in how the Trezor device displays auto-lock delays longer than a day. Previously, the confirmation dialog showed "48 hours" while the settings menu showed "2 days" for the same delay. The fix merges two similar formatting functions into one shared implementation so all screens use the same wording. It is a cosmetic bug fix, not a security vulnerability.

This commit adds a new way for Ethereum transaction definitions to include fixed text labels (called 'constant values') that are shown to the user during signing. It does not change how transaction data is parsed or signed, but it expands what untrusted display-format definitions can put on the device screen. The change is a feature addition, not a fix for a known bug, and there is no vendor statement that it is security-relevant.

This commit only adds two new import names (DateFormatter and RawFormatter) to an existing Python file in the Ethereum clear-signing module. It is a test-related change with no functional code modifications, no bug fixes, and no security-sensitive behavior changes.

This commit simply removes an unused on-screen message function called show_wait_text() from the Trezor firmware. There is no security fix or behavior change; it is a routine code cleanup.

This commit fixes a bug in the Trezor hardware wallet's user-interface code. Previously, certain simple on-screen messages were wrapped in a Python `with` block, which caused the underlying layout object to be cleaned up (dropped) as soon as the message was drawn. However, the system still held a reference to that layout and its background event-handling tasks were still running. Dropping it early could lead to a crash, a frozen screen, or undefined behavior while the device is showing important prompts such as asking the user to enter their passphrase on a host computer or displaying a 'please wait' message. The fix removes the `with` wrapper so the layout object stays alive until a new screen replaces it.

This commit removes support for a new Ethereum transaction type (EIP-7702) from Trezor hardware wallets. It is described by the developers as a temporary revert of a feature that will be re-added later. There is no indication this is a security fix; it is a feature removal for code organization.

This commit only updates version numbers and translation metadata. It changes no program logic, fixes no bugs, and introduces no security-relevant behavior. There is nothing here that could be exploited or that changes how the device protects data.

This commit fixes a bug in the Trezor hardware wallet's Caesar UI layout where long lists of key-value properties (for example, transaction details shown on the device screen) could either crash debug builds or be silently cut off in production builds. The fix replaces a fixed-size container with a lazy, unbounded one, so all properties are rendered and none are dropped. There is no direct evidence in the commit that this was exploited or treated as a security vulnerability by the vendor.

This is a code cleanup and type-safety refactor for the Monero parts of the Trezor firmware. It adds stricter type hints, asserts that certain values are not missing, and fixes a minor return-value bug in a helper that encrypts data. There is no direct evidence this commit fixes an active security vulnerability, but it reduces the chance of future bugs by making assumptions explicit.

This commit is a routine developer tooling change. It turns on stricter Python type checking (Pyright) for the emulator script and some test helper scripts, and makes small code adjustments so those files pass the new checks. There is no change to the security-critical Trezor firmware itself, wallet operations, or cryptographic handling.

This commit changes how the Trezor firmware build and test tooling handles the Tropic secure-element emulator. Previously, Tropic support was disabled by default in Unix emulator builds and had to be explicitly enabled; now it is enabled by default and the test harness starts the Tropic model automatically. It also refactors port allocation so each emulator worker reserves a wider block of ports. The changes are confined to build scripts, CI workflows, and test/development tooling. There is no direct fix for a runtime vulnerability in shipped firmware, but enabling a hardware-security emulator by default could theoretically expose test-only code paths or secrets if the emulator is misused outside of testing.

This commit is a routine code reorganization: it moves existing test-only helper code from the project's internal test directory into the public `trezorlib` Python package as a new `testing` module. The moved code includes utilities for handling emulated devices during tests, translation blob helpers, and Bitcoin compact-size encoding. There is no change to the firmware that runs on Trezor devices, no change to production cryptography, and no security fix or vulnerability introduced.

This commit adds support for a new Trezor hardware model, the T3T2. It is a product enablement change that introduces board definitions, memory layouts, bootloader hashes, vendor headers, and Python tooling entries for the new device. There is no indication of a security vulnerability or a fix for one.

This commit adds support for a new Trezor development board called D003 (based on an STM32U5 Nucleo evaluation kit). It is purely an enablement change for internal hardware bring-up: new configuration files, memory layout, bootloader hash, vendor headers, and build-system entries. There is no indication it fixes a security bug or introduces a vulnerability in shipping products.

This commit adds support for a new microcontroller chip (the STM32U5A5) to the Trezor firmware build system. It is a hardware-enablement change: it wires up the right compiler flags, linker scripts, memory layouts, and trustzone settings so the existing code can compile and run on the new chip. There is no user-facing behavior change, no bug fix, and no security patch in this diff.

This commit hardens how Trezor compares secret values (passwords, PINs, cryptographic tags, and checksums) so that an attacker cannot learn information by measuring how long the comparison takes. It also adds a fault-injection check: if a glitch skips the comparison loop, the device is supposed to detect that and halt. The change is defensive and reduces the risk of side-channel and fault attacks, but it does not by itself fix a known, directly exploitable bug.

This commit is a small test-only UI adjustment for the Trezor hardware wallet's Caesar layout. It changes when a menu icon is reported as visible in automated UI snapshots, limiting it to the last page of a multi-page flow. The code change only affects test fixtures and snapshot hashes, not user-facing security behavior. There is no indication this fixes a security vulnerability.

This is a minor user-interface polish change for the Trezor hardware wallet's Caesar layout. It removes an unnecessary blank line from transaction summary screens when either the amount label or the amount value is empty. There is no security relevance: it does not change what the device signs, how it signs, or any cryptographic behavior. The large diff is mostly updated test screenshot hashes reflecting the slightly different screen layout.