Trezor firmware

This is a simple code cleanup: the developer removed a local alias named NOISE_TAG_SIZE_BYTES and replaced every use of it with the existing official constant NOISE_XXPSK3_TAG_SIZE. The numeric value and behavior of the code are unchanged, so there is no security impact.

This commit hardens the Noise protocol code used in Trezor firmware by adding size limits and nonce limits to prevent two cryptographic problems: encrypting or decrypting messages that are too large for the protocol, and reusing the same encryption nonce after the counter wraps around. Reusing a nonce with AES-GCM can destroy the confidentiality of messages and allow attackers to forge fake messages. The patch also wipes sensitive context data more thoroughly when errors occur, reducing the chance that leftover key material could leak.

This commit removes an unused translation string called 'stellar__timebounds' from the Trezor firmware's translation system. It is a cleanup/refactoring change with no visible effect on device behavior or security. The signatures.json file was also updated because removing a string changes the cryptographic hash (merkle root) used to verify translation files.

This commit improves the Stellar signing experience on Trezor hardware wallets by letting users see which network (Mainnet, Testnet, or Futurenet) a transaction is for before approving it. Previously, the network was intentionally hidden from the main confirmation flow after a redesign, which could lead someone with accounts on both mainnet and testnet to accidentally approve a mainnet transaction they only intended for testnet. The fix adds the network name to an info menu on the final review screen for both regular Stellar transactions and Soroban authorizations. It also adds support for the Stellar Futurenet network passphrase. This is a security/usability improvement rather than a remote-exploitable vulnerability.

This commit changes the on-screen display component used by one user-interface helper from a short paragraph container to a long one, raising the maximum number of info lines that can be shown from 4 to 18. The commit message explicitly calls it a 'preparatory commit' and there is no indication of a security bug or fix.

This commit fixes a display bug in Trezor hardware wallets running the 'Caesar' user interface. In certain Ripple and Stellar transaction confirmation screens, a helpful description label (for example, explaining that a shown number is a fee limit or payment amount) was accidentally left off. The fix makes sure the description appears alongside the value, so users are less likely to misread what they are approving. It is a user-interface clarity issue rather than a direct theft-of-funds vulnerability, but it could contribute to a user approving a transaction they do not fully understand.

This commit only regenerates translation files after some text labels were moved from one category to another (for example, 'Authenticate' and 'Wipe' were changed from general words to button labels). There is no code behavior change, no bug fix, and no security relevance visible in the diff.

This commit is a straightforward internal cleanup of translation key names. It changes labels like 'words__continue_anyway' to 'buttons__continue_anyway' in code that displays on-screen buttons and menu items. The actual user-facing text shown on the device is unchanged; only the internal identifier used to look up that text was renamed. There is no security-relevant change.

This commit fixes a bug in Trezor's Ripple (XRP) signing code. When a payment request included a destination tag of 0, the device treated it as if no tag was set, so it did not show or verify the tag. Because destination tags are used to route funds to the correct recipient on exchanges, omitting tag 0 could let an attacker trick a user into approving a payment that looks tagless but actually sends to tag 0, potentially sending funds to the wrong account or making them hard to recover.

This update fixes a bug in how Trezor handles certain Monero 'sweep' transactions. In a sweep, one output is a fake zero-value decoy with a random address, and the device normally skips checking that the change address belongs to the wallet. A malicious computer app could exploit that skip by claiming the real payment recipient's address is the change address. The device would then encrypt the recipient's output using the wallet's own secret view key, making the money effectively unspendable by the recipient and unrecoverable by the sender. The fix adds a check: if the unvalidated change address appears on any output that actually carries money, the transaction is rejected. Honest sweeps, where the decoy carries zero coins, still work normally.

This commit adds a new user-interface option for the Trezor Safe 5 (Delizia) that lets certain confirmation screens use a red 'danger' hold-to-confirm style instead of the normal green one. It is purely a visual/theming change and does not alter what the device signs, what it allows, or any security policy. The large diff is mostly updated test screenshot hashes caused by the changed colors/text.

This commit removes an unused cryptography helper module from the actual Trezor firmware and keeps it only in the test suite. There is no security bug being fixed here; it is a routine cleanup to avoid shipping dead code.

This is a cleanup change that stops generating unused bootloader hash files for newer Trezor models (D002, T3T2, T3W1). These models already verify the bootloader using a different mechanism (UCB with post-quantum signatures), so the old hash files were never actually used. The commit deletes the stale files and removes their #include references. There is no security vulnerability here.

This is a tiny command-line interface (CLI) fix for the Stellar-related commands in Trezor's Python library. Two different options were accidentally using the same short flag '-n': one for '--address' and one for '--network-passphrase'. The patch changes '--network-passphrase' to use '-p' instead, matching another Stellar command. This is mainly a usability bug, not a direct security vulnerability, because users could not reliably select the intended option by short flag.

This commit moves the public keys used to verify coin/token definitions from Python code into a new Rust module. It also makes development-signed definitions accepted on non-production builds, similar to an existing feature for translations. The change is a build/configuration refactor rather than a fix for an active security flaw. Production firmware still requires production signatures; dev keys are only accepted when the `dev_keys` feature is enabled, which is intended for development builds.

This commit only refreshes test data files: it updates a translation signature metadata file and regenerates UI test fixtures. There is no code change, no security fix, and no indication of a vulnerability being addressed.

This is a harmless internal cleanup: the word "Network" was previously stored separately for Cardano and Ethereum, and is now merged into a single shared translation key called words__network. No user-facing text, security behavior, or transaction logic changed.

This update fixes a security flaw in Trezor's older hardware wallet firmware for Ethereum staking operations. Previously, when a user tried to 'unstake' or 'claim' staked ETH, the device did not reliably block ETH from being sent along with the transaction (msg.value), even though those smart-contract functions are not supposed to accept money. It also did not strictly check that the transaction was on the correct Ethereum network (chain ID), which could have allowed a malicious or accidental transaction on one network to be replayed on another. The fix enforces zero ETH value for unstake/claim and ties each allowed contract address to its proper network.

This update tightens the rules for two Ethereum staking operations—unstake and claim—on Trezor hardware wallets. Before the fix, the device did not verify that the user was on the correct Ethereum network (chain ID) and did not block ETH from being attached to unstake/claim transactions. Because those contract functions reject incoming ETH, any ETH sent with them would normally be lost. The patch now rejects such transactions before they can be signed, preventing accidental or malicious loss of funds and cross-chain replay attacks.

This commit only updates translated text strings in Czech, German, and Spanish language files, plus the corresponding translation signature metadata. There are no code, logic, or security-related changes.

This commit adds an Indonesian language translation file (id.json) to the Trezor firmware. It is a localization-only change with no executable code, no security logic, and no functional behavior changes. There is no indication this introduces any security issue.

This commit fixes a user-interface detail on Trezor hardware wallets: when displaying an Ethereum public key on the device screen, it now also shows the derivation path (the sequence of numbers that identifies which account/key the public key belongs to). Previously only the public key was shown. This is a usability and transparency improvement, not a fix for a code vulnerability that could be exploited remotely.

This commit only adds a new test case for the Stellar cryptocurrency feature. It records an expected transaction signature for a 'remove signer' operation so the device can be tested against a known-good value. There is no code change, no bug fix, and no security-relevant behavior change.

This update fixes how the Trezor hardware wallet displays a Stellar 'Set options' operation when a signer is being added or changed. Previously, the device did not show the signer's 'weight' value on its screen. Because weight controls how powerful a signer is (for example, how many signatures are needed to approve a transaction), a user could unknowingly approve a high-weight signer that gives an attacker more control over the account. The fix now shows the weight during confirmation, so users can spot suspicious changes before signing.

This commit adds new Rust code that lets other parts of the Trezor firmware call existing C-language ECDSA cryptographic functions (signature verification and public-key recovery). It is a feature addition that exposes already-trusted crypto code through a thin Rust wrapper. There is no indication in the commit that it fixes a bug or vulnerability.