Trezor firmware

This commit simply removes an unused error code named INVALID_DATA from the Trezor hardware wallet's new THP (Trezor Host Protocol) code. It deletes the numeric constant, the matching Python exception class, and the mapping that translated the error number into that exception. There is no change to how data is validated or how errors are handled; it only cleans up code that was never referenced.

This commit fixes a Bluetooth Low Energy (BLE) crash in Trezor hardware wallets caused by a stack overflow. The patch does two things: it stops placing the device advertising name on the thread stack by using a static buffer instead, and it increases the BLE management thread's stack size from the default to 2048 bytes. The change reduces the chance that a long or specially crafted device name could corrupt nearby memory or crash the BLE subsystem. There is no vendor statement that this is a security vulnerability, and no independent researcher is credited.

This commit changes how the older Trezor One (legacy) firmware displays Ethereum transaction fees on the device screen. Previously, small per-gas fee values could be shown in 'Wei' (the smallest Ethereum unit) instead of always using 'Gwei'. The fix makes per-gas fees consistently display in Gwei, matching the newer Trezor Core firmware. This is a user-interface consistency fix that could have minor security relevance because confusing fee units might lead a user to misread or misapprove a transaction fee, but the commit itself does not change any signing logic or cryptographic checks.

This commit is a small feature update for the Trezor hardware wallet's Bluetooth pairing system. It adds a new 'app_name' field to the cached information stored alongside each paired device's MAC address and host name. The change is purely additive and does not appear to fix or introduce any security vulnerability. It updates protocol definitions, device menu display helpers, pairing logic, and generated code in multiple languages, plus related tests.

This is a routine developer tooling change. It extends an internal version-bumping script so it can also update plain-text VERSION files (used by a new Bluetooth project), in addition to the existing C header version files. There is no user-facing or security-relevant change to the firmware itself.

This commit only increases version numbers (patch levels) for four Trezor firmware components: the bootloader, production test tool, security monitor, and Bluetooth Low Energy module. There are no code logic changes, bug fixes, or security-related modifications in the diff itself.

This commit tightens the rules for a Trezor pairing request by making both the host name and app name mandatory. Previously, the app name was optional, which could have led to a confusing or misleading pairing screen on the device. The change helps ensure users see complete, accurate information before approving a connection.

This is a small Python library fix for the Trezor hardware wallet's new Bluetooth-style pairing protocol (THP). It makes the client send the computer's real hostname and the application's name during pairing, instead of always sending a generic placeholder. This helps users see which app and computer they are pairing with on their Trezor screen. It is a usability and correctness improvement, not a security vulnerability fix.

This commit simply adds a new build target called 'secmon' to a Docker build script. It changes two lines in a help message and a default list of build targets. There is no indication this is a security fix or introduces a vulnerability.

This commit is a small UI cleanup for Trezor hardware wallets. It stops on-screen scrolling text (marquees) from requesting animation frames when the text already fits in its allotted space. This saves battery and avoids unnecessary screen redraws, but it does not fix a security vulnerability.

This is a user-interface layout tweak for the Trezor hardware wallet's new 'Eckhart' design. It makes the first menu button visually overlap the screen header when there is no subtitle, and adds logic so the header is drawn on top if its buttons are being pressed. There is no security-relevant change here.

This commit tweaks how menu buttons behave on the Trezor Safe 5 (Eckhart layout). Previously, any menu button that was not fully visible on screen was completely disabled, so you could not tap it. Now only buttons that are fully hidden are disabled; buttons that are partially visible remain active, but their touchable area is trimmed so it does not overlap the top header. This is a user-interface polish change, not a fix for a cryptographic or firmware security flaw. It could slightly reduce the chance of a user accidentally tapping a half-hidden button, but it does not introduce or remove a meaningful security vulnerability on its own.

This commit is a minor visual polish change for the Trezor hardware wallet's user interface. It moves a small downward arrow icon slightly upward so it no longer overlaps menu text, and adds an automated test to ensure that spacing rule stays correct. There is no security-relevant change.

This commit adds a new feature to read pre-stored digital certificates from the Tropic secure chip inside Trezor hardware wallets. It does not change how keys are generated or signed, and it does not appear to fix a known bug or vulnerability. The new code is mostly about safely reading fixed-size data slots from the chip and exposing them to Python applications.

This is a routine code cleanup that moves Tropic chip constants (like which key slot is used for what) into a shared header file so multiple parts of the firmware can use the same definitions. It also updates the Python binding for signing to use the correct Ed25519 signature size and exposes two key-slot constants to Python. There is no security vulnerability here.

This commit fixes how a Trezor hardware wallet selects cryptographic pairing keys when establishing a secure session with the Tropic secure chip. Previously the code always used a single fixed key slot (likely a factory/unprivileged key). After the change, it tries to use a privileged pairing key if available, and falls back to an unprivileged key if not. It also adds a small delay to avoid a 'chip busy' error from the Tropic chip. The change is security-relevant because using the wrong pairing key could weaken the secure channel or cause it to rely on a less trusted factory key, but the commit itself does not describe an active vulnerability or attack.

This commit updates the Trezor Python library's device-authentication code to support a new hardware security chip (Tropic) in addition to the existing Optiga chip. It adds Ed25519 signature verification, new root public keys for the T3W1 device, and a check that both chips' certificate chains are issued by the same root authority. The change is a feature addition rather than a fix for a known vulnerability, but it strengthens the authentication process by making it harder for a device with a valid certificate from one root to pass authentication using a mismatched certificate from another root.

This commit adds a new secure hardware feature that lets the device read small protected data slots from a Tropic security chip. It is a feature addition, not a bug fix. The code includes the usual memory-access checks, so there is no obvious security flaw in the diff itself. However, it expands the attack surface by exposing another privileged operation to less-trusted firmware, and the review is limited because the underlying Tropic library code is not shown.

This commit fixes a build configuration bug for the Trezor T3W1 hardware wallet. The Tropic secure-element feature was being compiled in, but the feature flag that tells the rest of the firmware to actually use it was not being registered. The change adds 'tropic' to the list of available features so the firmware can correctly enable Tropic support. There is no direct evidence in the commit of a security vulnerability or exploit.

This commit updates the Trezor hardware wallet's device-authentication feature so it can optionally use a second secure chip (Tropic) in addition to the existing Optiga chip. It refactors certificate parsing into a helper and renames the proof fields from generic names to optiga_* and tropic_*. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a feature addition enabling a new hardware variant.

This commit rewrites a function that reads data stored across multiple secure memory slots on Trezor's Tropic secure element. The rewrite reduces memory usage and avoids reading unused slots, but it also changes how the code checks slot boundaries and how it validates that the declared data length actually fits within the requested slot range. A subtle bug in the new code could allow reading more slots than intended or mishandling short terminal slots, though the commit appears aimed at hardening rather than introducing a vulnerability.

This commit renames existing fields in a device-authentication proof message and adds optional fields for a second security chip (Tropic). It is a schema-only change across generated protobuf bindings; there is no new executable logic shown. By itself it does not create a vulnerability, but it changes the public API used to verify whether a Trezor device is genuine.

This commit is a straightforward code cleanup in the Trezor firmware's THP (Trezor Host Protocol) layer. It renames a function and changes how CRC checksums are computed, but does not appear to fix or introduce a security vulnerability. The behavior remains functionally equivalent: invalid checksums are still rejected, and valid payloads are still accepted.

This commit simply doubles the initial wait time between retries when sending data over the Trezor's THP (Trezor Host Protocol) channel and slightly adjusts the maximum timeout. It is a routine tuning change with no visible security implications.

This commit swaps out two pre-built binary firmware files for the T3W1 hardware model and updates the matching cryptographic hash values in a header file. The change is described as a routine chore with no changelog entry. There is no visible source code change, no security explanation, and no disclosed vulnerability.