Trezor firmware

This commit only updates test data. It corrects the capitalization (checksum) of Ethereum addresses used in automated tests and refreshes the expected screen-shot hashes those tests compare against. There are no changes to the actual Trezor firmware code that users run, so this cannot affect real devices or user funds.

This commit changes the Trezor Python library so that, when setting up a Trezor Model One (the original Trezor 1 device), it now performs an entropy check by default if the device runs firmware 1.13.1 or newer. Previously, the library only enabled this check on newer Trezor models and treated all Model One devices as not supporting it. An entropy check helps verify the device is generating randomness properly during wallet setup. The change is a defensive fix to enable a security feature on a previously excluded device line, not a patch for an active vulnerability.

This commit is a routine cleanup that removes the old SCons build system files from the Trezor Core firmware repository. It deletes Makefiles, SConscripts, and related Python helper scripts, but does not change any firmware source code, cryptographic logic, or runtime behavior. The commit message explicitly says it is a chore with no changelog entry, indicating it is not a security fix.

This commit updates Trezor's embedded MicroPython interpreter from an older version to 1.28.0. It pulls in several upstream MicroPython bug fixes, including stricter buffer-size checks for converting integers to bytes, a new stack-safety API, preventing Ctrl+C from interrupting frozen boot code, fixing a stdout write return value, and blocking accidental creation of bytearrays from plain strings without an encoding. The changes are mostly defensive hardening and compatibility fixes rather than a single known exploit patch. There is no vendor statement that this is a security fix, no CVE, and no credited researcher.

This is a large but straightforward internal cleanup: the project switched from using the MicroPython `ubinascii` module's `hexlify`/`unhexlify` functions to the standard Python `bytes.hex()` and `bytes.fromhex()` methods. The change removes the `ubinascii` module from the firmware build and updates many source and test files to use the new built-in methods. There is no security fix or vulnerability being patched here.

This is a code cleanup change in Trezor's firmware that swaps one MicroPython internal helper for another. It replaces calls that create byte or string objects from a vstr buffer with newer, purpose-built helpers. The commit message says the new string helper also does UTF-8 validation, which can be skipped where performance matters. The change itself does not introduce a known vulnerability; it is a refactor to match upstream MicroPython conventions.

This commit is a large but purely mechanical code cleanup: it replaces the custom STATIC macro with the standard C keyword static across many MicroPython module files. There is no change to program logic, security boundaries, or behavior. It also removes build-system workarounds that were only needed because the old macro was being abused to expose internal functions.

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 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.

This commit only adds new automated tests for signing Stellar Soroban authorizations. It does not change any production firmware, wallet logic, or cryptographic code. There is no security vulnerability here.

This commit is a straightforward code cleanup: it moves several Stellar Soroban serialization helper functions from an operation-specific file into a shared writers module so both transaction signing and standalone authorization signing can use the same code. No behavior changes, bug fixes, or security fixes are visible in the diff.

This commit is a straightforward code cleanup: it moves helper functions for formatting Stellar Soroban smart-contract values and showing confirmation screens from one file to another shared file. No security behavior changes are visible in the diff. The only functional tweak is narrowing an exception handler from a broad 'except Exception' to 'except OverflowError' when formatting timestamps, which is a minor hardening improvement, not a vulnerability.