Trezor firmware

This commit is a routine code cleanup that updates Trezor firmware to match a newer MicroPython version where built-in module names dropped the 'u' prefix (for example, 'uos' became 'os' and 'ustruct' became 'struct'). It renames imports, configuration flags, and source file references, and removes old mock files. There is no security fix or vulnerability here.

This commit only updates the firmware version number from 2.12.4 to 2.12.5 in the source code and translation files. It does not change any security-related logic, fix any bug, or alter any cryptographic behavior. It is a routine release bookkeeping change with no security relevance.

This is a routine build-system cleanup for the Trezor firmware. It switches the internal 'trezor_lib' Rust crate to be built with the project's own 'xbuild' tool, removes transitional feature flags, and reorganizes Cargo.toml files. There is no indication this change fixes or introduces a security vulnerability.

This commit adds Bluetooth Low Energy (BLE) support for the Trezor T3T2 hardware model. It introduces new board configuration files, pin mappings, build scripts, and firmware binaries for the Nordic nRF54LS05A BLE radio used in T3T2. There is no indication in the commit that this fixes a security bug; it appears to be a feature addition enabling BLE functionality on a new device variant.

This commit is a large but straightforward internal refactoring: the cryptographic code is moved from one Rust crate (`rtl`) into a new dedicated crate (`crypto`), and all project dependencies are updated to point to the new crate. The actual cryptographic algorithms, build flags, and source files remain the same. There is no indication of a security bug fix or a vulnerability being introduced.

This commit is a code cleanup that moves how Trezor firmware handles fatal errors and shutdowns between its internal software layers. It does not add new user-facing features or change security protections. The main risk is that reorganizing low-level error paths could accidentally introduce a bug, but the diff itself does not show a vulnerability being fixed or introduced.

This commit changes a single on-screen label in the Trezor bootloader from lowercase 'Change fw vendor' to uppercase 'Change FW vendor'. It is purely a cosmetic wording fix with no security relevance.

This commit adds support in Trezor's Ethereum clear-signing feature for transactions that contain multiple embedded subcalls (like a multicall). Previously, only a single embedded call could be clearly displayed. The change lets the device show each subcall separately with labels like "(Subcall #1)" and handles both a single shared recipient address or a parallel list of recipients. It is a feature addition, not a fix for a known vulnerability.

This commit only adds new automated tests for Trezor's Ethereum 'clear signing' feature. It includes a test case for an Aave multi-call transaction, a matching test data blob, and expected screen snapshots for different device models and languages. There are no changes to the actual firmware code that runs on the device, so this commit does not introduce or fix a security vulnerability.

This commit fixes a user-interface bug in Trezor's Ethereum 'clear signing' flow where the transaction's native ETH amount could be shown twice on the device screen. The old code tried to avoid duplication by checking whether an 'AmountFormatter' field was present, but that check missed cases where the same amount was rendered by other field types. The new code compares the actual rendered strings and suppresses the summary amount only when it exactly matches a field already displayed. There is no security vulnerability here; it is purely a display-quality fix.

This commit adds a new display formatter for Ethereum clear signing. It lets a transaction descriptor map numeric enum values (like 1 or 2) to human-readable labels (like 'stable' or 'variable') on the Trezor screen. The change is purely additive and includes tests. There is no indication it fixes a security bug or introduces a vulnerability; it is a feature implementation.

This commit only adds a new automated test case for an existing Ethereum transaction display feature. It does not change any production firmware code, so it cannot introduce a security vulnerability or fix one. It is purely a test-data addition.

This commit adds a new Trezor firmware feature called 'clear signing' for nested Ethereum calls. It lets the device understand when a transaction wraps another contract call (like a router or multicall) and tries to show the user readable details about the inner call instead of just a blob of hex. The change is a feature addition with built-in safeguards: nested parsing is limited to one level, ambiguous fields like sender and value are blocked inside nested calls, and failures fall back to showing raw hex rather than aborting the whole transaction. There is no indication in the commit that this fixes a known security bug; it reads as a defensive new capability.

This commit is a test-only addition for Trezor's Ethereum 'clear signing' feature. It adds new test cases and makes a small production-code tweak so that enum display-formatters can accept byte values (converted to integers). The change is not described as a security fix, and the production change is minor and defensive: it broadens accepted input types rather than fixing a crash or bypass. There is no evidence of a disclosed vulnerability or exploit.

This commit is a code-quality cleanup that changes many function parameters from signed integers (`int`) to unsigned size types (`size_t`) where only non-negative lengths or sizes make sense. It also removes some now-unnecessary negative-value checks and adjusts callers/tests accordingly. The change is defensive: using `size_t` prevents accidental negative lengths from being interpreted as huge positive values, which can cause memory corruption or information leaks. The commit itself does not claim to fix a specific vulnerability, and no external security advisory is supplied.

This commit adds a new Trezor feature that lets users sign Stellar Soroban smart-contract authorization entries. The device now supports a new message type where it derives the user's Stellar address, shows confirmation screens, and produces an Ed25519 signature over a protocol-defined authorization payload. The change is a feature addition rather than a bug fix, and the signing flow includes user confirmation steps.