Trezor firmware

This commit updates a bootloader linker script for a new STM32U58-based Trezor variant to support an alternative 'PQ' (post-quantum) bootloader header format. It adds a code-size symbol, a small padding section, and changes how the bootloader image is padded to its maximum size. There is no direct evidence in the commit that this fixes a security vulnerability; it reads as a build/enablement change for a new hardware configuration.

This is a small internal code cleanup in the Trezor firmware's Ethereum transaction confirmation flow. It changes several function parameters from 'Iterable' (a general 'can be looped over' type) to 'Sequence' (a type that supports indexing and has a known length). The commit title says the goal is to 'avoid allocation' because the code no longer needs to convert the items into a list before passing them to the UI. There is no direct evidence in the commit of a security vulnerability being fixed; it reads as a performance or memory-efficiency refactor.

This commit turns off several unused features in the MicroPython interpreter that runs on Trezor hardware wallets. It is a hardening change that reduces the amount of code available to an attacker, but it does not by itself fix a known, exploitable bug. The commit message explicitly calls it a routine cleanup ('chore') and says it needs no changelog entry.

This commit only updates automated test scripts and recorded test snapshots (fixtures) for the Trezor firmware. It adds support for testing a new backup method called N4W1 alongside the existing on-screen display backup method. There are no changes to the actual device firmware, wallet logic, or security-critical code, so this commit does not introduce or fix a security vulnerability.

This commit fixes a bug in the tool that builds Trezor hardware wallet flash images. Previously, when combining the boardloader, bootloader, and firmware into one file, later sections were placed too early because earlier files were smaller than their reserved flash space. The fix pads the gaps with zeros so each piece lands at its correct memory address, preventing the resulting image from failing to boot. It is a build-time tooling fix, not a runtime vulnerability in the device itself.

This commit is a straightforward build-system cleanup. It removes special-case layout feature bundles (like layout_bolt_d001 and layout_bolt_d002) and replaces them with separate, explicit display-type features (display_mono, display_rgb565, display_rgba8888). Model configuration files now list the display type directly alongside the layout type. There is no change to runtime code, no bug fix, and no security-related behavior.

This commit fixes a labeling mistake in the Trezor firmware's protocol definition: eleven Monero request messages were incorrectly marked as traveling from the device to the host, when in reality the host sends them to the device. The change only updates metadata in generated host-side descriptors; the firmware itself does not use this metadata, so on-device behavior is unchanged. It is a correctness fix for host libraries, not a patch for an exploitable device bug.

This commit is a routine cleanup: it removes two old, already-deprecated fields from the messages that Trezor devices and apps use to exchange passphrase information. The fields were marked deprecated in firmware version 2.3.0 and are no longer used. Removing them does not change active behavior and does not fix or introduce a security vulnerability.

This commit is a routine cleanup: it removes two old, already-deprecated message types related to passphrase handling from Trezor's protocol definitions and generated code. There is no security fix or vulnerability being patched here; the messages were marked deprecated years ago and are now being deleted entirely.

This commit undoes a previous change in the Trezor client Rust library. The original change made the software send an empty passphrase when using standard (non-hidden) wallets. The revert restores older behavior where, if the device is not asking for the passphrase on-device, the client acknowledges the passphrase request without providing an empty string. The practical effect depends on how the Trezor device firmware interprets the two acknowledgment types: one with an explicit empty passphrase and one without a passphrase field. It could affect which wallet derivation path or seed is used, potentially causing users to see a different wallet than expected, but the commit itself does not clearly introduce theft or remote exploitation.

This commit removes an unused Rust helper method that checked whether a passphrase should be entered on the Trezor device. It is a routine cleanup with no visible security effect.

This is a minor code cleanup in the Rust Trezor client. It simplifies how the software responds when a Trezor device asks for a passphrase. The old code checked whether the device wanted the passphrase entered on the device itself; now it always tells the device to enter the passphrase on the host computer. The commit message says the on-device path is deprecated and no longer used. There is no security-relevant change visible in the diff.

This commit fixes an out-of-memory (OOM) crash during Ethereum payment-request signing on the Trezor Safe 3 (T2B1). The fix wraps UI layout construction in a temporary async task so the device's garbage collector can reclaim memory sooner. It is a reliability/DoS-style bug rather than a theft-of-funds vulnerability.

This commit is a code cleanup that changes how user-interface layouts are managed in the Trezor firmware. It wraps layout objects in explicit context managers (using `with ... as layout:`) and converts several synchronous-looking helper functions into proper async functions. There is no direct evidence in the commit that this fixes an exploitable security bug; it appears to be a defensive refactoring to enforce clearer scoping of UI resources.

This commit fixes a bug in the Trezor client library where users with a standard wallet (no passphrase) were still being prompted to enter a passphrase on their Trezor device. The fix ensures that for standard wallets, the client replies with an empty passphrase instead of incorrectly asking the device to handle it. This is a usability and workflow bug rather than a direct theft-of-funds vulnerability, but it could cause confusion or lead users to enter an unintended passphrase.

This update fixes a bug in Trezor hardware wallets where the device would not properly lock itself when only SD card protection was enabled and no PIN was set. In that configuration, an attacker with brief physical access could potentially keep the device unlocked and use it without needing to enter a PIN or provide the SD card secret, bypassing the intended security protection.

This commit fixes a timing weakness in how a Trezor hardware wallet checks the authenticity of a 'credential' used in its Trezor Host Protocol (THP). Previously, the device compared two secret codes with a standard equality check, which can leak information through tiny timing differences. The patch switches to a constant-time comparison function and adds a length check first. This is a defensive hardening change against side-channel attacks, but the commit message does not frame it as a security fix and no exploit is described.

This update fixes a bug where a Trezor hardware wallet with SD-card protection enabled could not be locked if no PIN was set. The device should be lockable whenever SD protection is active, because the SD card itself acts as a security factor. The change makes the homescreen use a broader 'can lock' check instead of only checking whether a PIN is configured. A new automated test also verifies that pressing and holding the screen can lock the device in this configuration.

This commit replaces internal programming assertions (which crash the device if they fail) with proper error handling for Ethereum transaction signing when a payment request is involved. It ensures that if someone supplies a payment request verifier, the transaction must have zero data bytes and must actually include a payment request object. Without the fix, a malformed or unexpected input could trigger an assertion failure instead of a clean error, potentially causing the device to crash or behave unpredictably during signing.

This commit is a routine version bump for a Trezor firmware release. It only changes version numbers in header files and translation metadata, plus updates the signed translation package reference. There are no code changes that affect security or device behavior.

This commit fixes a build configuration issue so that debug builds of Trezor firmware, bootloader, and production-test firmware automatically enable a visual 'ui_debug_overlay' feature. That feature displays a small red square marker in the top-right corner of the screen, making it obvious when a debug/non-production build is running. It is a UI/UX and build-system change, not a fix for an exploitable security vulnerability.

This commit adds a new helper script that lets developers check whether a signed Trezor firmware file truly matches its unsigned counterpart and whether its digital signature is valid. It is a defensive verification tool, not a fix for a security flaw, and introduces no vulnerability in the device code itself.

This commit is a feature addition to Trezor's internal production-test firmware. It replaces generic string-based error messages with a structured, numbered error-code system. There is no direct security vulnerability being fixed or introduced; it is a maintainability and diagnostics improvement for factory testing tools.

This commit is a code cleanup that wraps more on-screen UI layouts in a new 'layout context' scoping mechanism. It changes how layout objects are created and awaited, but does not add or remove security checks. The main risk is that any mistake in the refactor could cause a layout to be used outside its intended scope, but the diff itself shows consistent mechanical changes rather than a security fix or vulnerability.

This commit only updates automated test scripts for the Trezor hardware wallet. It changes how the test code simulates button presses during a wallet backup flow to match the actual device behavior. There is no change to the firmware or wallet security itself.