Trezor firmware

This commit tightens validation in Trezor's Ethereum 'clear signing' feature. It now rejects cases where a host computer tells the device to parse a variable-length type (like a string or byte blob) as if it were a fixed 32-byte value, or vice versa. This reduces the chance that a malicious or buggy host could trick the device into misreading transaction data, but the commit itself does not claim to fix a specific known attack.

This commit replaces several 'assert' checks in the Ethereum 'clear signing' code with proper error handling. In production firmware, asserts can be stripped out or behave differently than expected, so replacing them with explicit error raises makes the code more robust against malformed or malicious transaction data. The change is defensive hardening rather than a clear fix for an active exploit.

This commit fixes an off-by-one-style bounds check in the Ethereum clear-signing code on Trezor hardware wallets. The old check only verified that the starting position was inside the data, but did not verify that the code was about to read 32 bytes from that position. As a result, a malformed Ethereum transaction or message could trick the device into reading past the end of a buffer while decoding human-readable fields. The fix now checks that offset plus 32 bytes does not exceed the data length before reading.

This commit adds a new feature to Trezor Ethereum signing that lets the device ask the connected computer or phone for extra token/contract display information during a transaction. It is a feature addition (not a direct bug fix), so it mainly changes how the wallet and device talk to each other. There is no clear security vulnerability visible in the diff, but any new request/response protocol introduces places where a malicious or buggy host could supply misleading data, and the device must carefully validate what it receives. The commit does not itself describe a security issue or credit a researcher.

This commit adds support for a new 'To' container path in Trezor's Ethereum clear-signing feature. It lets the device reference the transaction recipient when formatting token amounts, which is useful for displaying ERC-20 transfers and approvals correctly. The change is a feature addition, not a clear security fix, and there is no evidence of a disclosed vulnerability.

This commit tightens a security rule in Trezor's Ethereum signing code: payment requests can now only be used with plain ERC-20 token transfers. Previously, the code may have allowed payment requests with other smart-contract calls, which could let a malicious app or service trick a user into approving a different transaction than expected while still showing a familiar payment-request screen.

This commit adds a new feature to Trezor's Ethereum signing flow: the device can now ask the host computer mid-transaction for extra token or display-format definitions. The main production code change is small and appears to fix a token-resolution bug in clear signing by preferring a token returned from the parsed field data over the one looked up from the static definitions. Most of the diff is new and updated test code exercising the new request/response mechanism and renaming helpers from 'erc7730' to the more generic 'display format'.

This commit changes how Trezor displays Ethereum token-approval amounts that exceed a safety threshold. Previously, the code returned 'None' for such large amounts, and the user interface fell back to a generic 'Unlimited amount' warning. Now the formatter explicitly returns a special 'AboveThreshold' marker carrying the text 'Unlimited', and each device UI layout uses that marker to show the same warning and display text. The change is a user-interface refinement, not a fix for a cryptographic bug or a remote exploit. It does, however, make the 'unlimited' signal explicit rather than implicit, which slightly reduces the chance that a future UI change would accidentally treat a huge allowance as an ordinary amount.

This commit only adds new expected screen-shot fingerprints (hashes) for automated user-interface tests of Ethereum token-definition request features. It does not change any firmware, application, or cryptographic code. There is no security-relevant change in the shipped product.

This commit updates a third-party vendor library called ts-tvl from one version to version 2.4. No actual code changes are visible in the supplied materials, and no security relevance is stated. It appears to be a routine dependency maintenance task.

This is a routine configuration cleanup for the Tropic secure-element model used in Trezor hardware wallets. It changes how firmware version numbers are written into a test/tooling config file (from a manually encoded binary blob to a plain version string) and explicitly pins a second firmware version to 1.0.0. There is no indication this fixes or introduces a security vulnerability.

This commit simply deletes two unused helper functions that set padding for notification screens in two different visual themes. There is no security relevance: no behavior changes, no bug fixes, and no attacker-accessible surface is introduced or removed.

This commit changes how Trezor devices reveal a passphrase on screen while typing. Previously, the revealed passphrase would hide again if the user's finger slid outside a specific extended area below the input box. Now, the passphrase stays visible until the user simply lifts their finger anywhere on the screen. This is a user-experience refinement, not a security fix or vulnerability.

This is a routine cleanup change that removes an unused visual border feature from the Trezor firmware's Delizia user interface. It does not change any security-sensitive behavior; it only simplifies the code by deleting a function that always returned zero-width borders and updating two places that called it to no longer use a border wrapper.

This commit changes how Trezor hardware wallets display passphrase entry on screen. Previously, the passphrase characters were shown in plain text as the user typed them. After this change, already-typed characters are hidden (shown as dots or asterisks), with only the most recently typed character briefly visible. The user can press and hold in the input area to reveal the full passphrase for verification. This is a security/usability improvement to reduce shoulder-surfing risk, not a fix for an exploitable vulnerability.

This commit fixes a UI bug in how the Trezor hardware wallet counts and displays the last character of a passphrase when it contains multi-byte UTF-8 characters (such as emoji or accented letters). Previously, the code measured length in bytes and sliced the string by byte position, which could split a multi-byte character and produce a broken or incorrect last-character display. The change adds proper character-based counting and a safe way to retrieve the last character. It is a correctness/robustness fix rather than a clear security vulnerability, and there is no evidence it was disclosed or exploited as a security issue.

This commit is a straightforward code cleanup: it takes one large Rust source file for the Trezor hardware wallet's homescreen and splits it into three smaller, logically organized files (header, notification center, and helpers) plus a module entry point. No user-facing behavior, security logic, or data handling changed.

This change widens the code's error-swallowing behavior during wallet setup so that I/O problems (like a disconnected computer) don't crash the backup flow and still show a success screen. It is described as a robustness/refactor fix, not a security fix. There is no direct evidence it introduces a vulnerability, but it does mean certain failures during backup could be silently ignored and the user might see 'success' even though something went wrong.

This is a minor cleanup of a GitHub Actions CI workflow file. It removes an 'exclude' rule that was preventing a certain combination of test settings from running, but the excluded combination was already impossible because the matrix did not include those values. There is no product code change and no security relevance.

This commit only adds three new user-facing text strings for an existing hardware feature called N4W1 (likely a near-field communication tag workflow). It adds error messages for empty, non-empty, and damaged tags, plus updates translation indexes and a signature file. There is no code logic change, no bug fix, and no security-relevant behavior.

This commit only changes the text label on a bootloader button from 'INSTALL FIRMWARE'/'INSTALL FW' to 'INITIATE CONNECTION'/'Init connection' on three Trezor hardware wallet models. It is a user-interface wording improvement with no security or functional code changes.

This commit simply removes an unused Monero hashing helper (the 'Hasher' class and related C functions) from the Trezor firmware codebase. It deletes dead code, tests, and type stubs. There is no indication this fixes or introduces a security vulnerability.

This commit is a simple renaming cleanup. It changes identifiers like 'EthereumERC7730DisplayFormatInfo' to 'EthereumDisplayFormatInfo' and 'ETHEREUM_ERC7730_DISPLAY_FORMAT' to 'ETHEREUM_DISPLAY_FORMAT' across protobuf definitions, generated code, and tests. There are no functional changes to how data is validated, parsed, or displayed.

This commit only adds new user-facing text strings for a wallet backup feature called 'N4W1' (for example, prompts asking the user what kind of backup they want and a 'Reading tag...' message). It updates translation files, generated Rust translation code, and a mock file used for testing. There is no executable logic change, no bug fix, and no security-related change.

This commit adds support for a new Ethereum feature called ERC-7730, which lets a computer (like a wallet app) tell a Trezor device how to display and interpret smart-contract transaction data in a human-friendly way. It also changes the message format so apps can send multiple token definitions instead of just one. The change is large and touches many generated files, but it appears to be a feature addition rather than a fix for an existing security bug. Because it introduces new code that parses untrusted data from a host computer and uses it to format what the user sees on screen, it could create security risks if the parsing or formatting logic has flaws, but the diff itself does not show an obvious vulnerability.