Trezor firmware

This commit fixes a security bug in the Trezor hardware wallet's Bluetooth handling. When a user chose 'Forget all' Bluetooth pairings, the device was not clearing a special key used for a feature called THP (Trezor Host Protocol) credential authentication. As a result, after reconnecting, the device might trust the other side without asking the user to confirm again. The fix adds a call to invalidate that key whenever all Bluetooth pairings are erased.

This commit changes how a Trezor hardware wallet handles an internal error condition during user interactions. In debug builds using the new THP (Trezor Host Protocol) communication channel, the device no longer crashes with a 'FirmwareError' when a button-acknowledgment state is still pending. Instead, it logs the issue and continues. The old behavior could cause the THP channel to become desynchronized because the error path might write to the channel twice. The fix prevents a possible communication desync but deliberately suppresses a previously fatal internal-consistency check.

This Trezor firmware fix ensures a background task that handles on-device button prompts is properly shut down when a screen layout finishes. Previously, the signal meant to stop that task might not be delivered, leaving the task running. The patch uses a 'replace' flag to guarantee the stop signal is placed in the queue. A stuck button-request task could cause the device and host software to get out of sync, potentially leading to confusing UI states or unexpected behavior during wallet operations.

This commit only updates automated test files. It renames a test helper class from InputFlowNewCodeCancel to InputFlowNewWipeCodeCancel and adds expected screen-image hashes for a wipe-code cancellation test across many languages and device models. No firmware source code is changed, so this cannot affect real device security.

This commit only adds a new automated test that checks whether a user can cancel the setup of a wipe code on a Trezor device. It does not change any firmware code, user-facing behavior, or security logic. There is no security issue here.

This commit is a code cleanup: it removes unused title, description, and information parameters from the PIN/wipe-code setup confirmation flow and lets each device layout pick the correct text strings internally based on whether the user is setting a PIN or a wipe code. There is no obvious security bug introduced; it is a refactoring change with a [no changelog] tag.

This commit is a temporary hotfix that disables the Tropic secure-element randomness source in non-production builds to stop a Red Screen of Death (RSOD) crash triggered by the function rng_fill_buffer_strong. The change wraps the Tropic random-buffer mixing step in a PRODUCTION preprocessor guard, so it only runs in production firmware. In non-production/debug builds, the function will fall back to whatever other entropy sources remain (likely the STM32 hardware RNG plus optional optiga mixing). The commit message explicitly calls this a temporary fix and says to delete it later, so it is a workaround rather than a root-cause fix. There is no direct evidence in the commit that this is exploitable, but any change to cryptographic randomness generation in a hardware wallet is a security-sensitive signal.

This commit simply deletes an unused helper method named write_handshake_message that forwarded its work to another method. There is no functional change, no bug fix, and no security relevance visible in the code change.

This commit adds a safety check in the Trezor hardware wallet's code that handles a newer USB protocol (THP). Before encrypting and sending a message, it now asserts that the protocol state allows sending. The change is defensive and small, but the commit message implies there was a path where encryption could happen when sending was not allowed. Without more context, it is unclear whether this closes a real security bug or is just hardening.

This commit fixes a timing bug in the Trezor hardware wallet's user-interface code. Previously, the device could close its 'button request' task before the host computer had acknowledged the request, which could cause the communication channel (THP) to become confused by two messages sent too close together. The fix makes the device wait for the acknowledgement before finishing. There is no evidence in the commit or supplied references that this was a security vulnerability exploitable by an attacker, and the vendor did not label it as such.

This commit only changes how long a specific automated test job is allowed to run in GitHub Actions, shortening the timeout from 90 minutes to 40 minutes. It does not modify any firmware code, cryptography, user interface, or device behavior. There is no security relevance.

This is a routine code cleanup: a function is renamed from _handle_usb_iface to _handle_button_requests because it now handles button request messages, not just USB interface messages. A local variable is introduced for clarity. There is no security change.

This commit removes a flag called USE_INSECURE_PRNG from the production-test firmware build. That flag previously told the device to use a weak or insecure random number generator during factory testing. Removing it means the production-test firmware will now use the microcontroller's true hardware random number generator (TRNG) instead. Using a weak random source in a test environment could, in theory, affect security if any test keys, identifiers, or calibration data generated there were later reused or leaked, but this change is in a specialized factory-only firmware image, not the main wallet firmware users run.

This change is a code cleanup, not a security fix. It moves three copies of the same factory private key into one shared function so the code is easier to maintain. The actual keys and how they are used do not change, and the commit message explicitly calls it a refactor with no changelog entry.

This commit adds a development-only code path for Trezor hardware wallets that use the Tropic secure chip. In non-production firmware builds, if the device lacks the normal Trezor private key, it falls back to a publicly visible factory private key and a factory pairing key slot. This lets developers test devices that have not yet been provisioned with unique secrets. The change is wrapped in `#if !PRODUCTION` guards, so it should not compile into retail firmware, but it does embed a hardcoded private key in the source tree.

This commit refactors how Trezor firmware generates random numbers. It adds a new 'strong' randomness path that mixes the device's hardware RNG with entropy from external secure chips (Optiga and/or Tropic), and routes all randomness through a common internal API. It is a feature/cleanup change, not a disclosed security fix, but it touches critical cryptography code and changes how secure chips are used.

This commit is a code cleanup that makes all random-number generation in the Trezor firmware core go through one dedicated secure path (sec/rng). It also moves the old insecure test-only random generator into a separate file so it is only used in emulators and tests, not in real hardware. The change reduces the risk that a real device accidentally uses a weak random source, but the commit itself does not claim to fix a specific active vulnerability.

This commit adds a small workaround in the Trezor hardware wallet's random number generator code. The change allocates a slightly larger temporary buffer and only uses the inner portion, leaving unused 'bumper' bytes at the end. The commit message calls this a 'libtropic overwrite bug workaround,' suggesting an external library (libtropic) may write past the requested amount of random data. The patch does not fix the underlying library bug; it only pads the local buffer so any overflow lands in harmless scratch space rather than corrupting adjacent memory. Because this affects the cryptographic random number generator used for keys and secrets, a real overwrite could have security implications, but the diff itself does not show an actual vulnerability in Trezor code or prove the bug is exploitable.

This commit removes a helper function called random_xor() and replaces its use in the hardware wallet's PIN secret generation with a single, stronger random-number call. There is no direct evidence in the commit that this fixes an active security vulnerability; it reads as a code cleanup that simplifies how random bytes are produced before they are stored on the secure Optiga chip.

This commit swaps in two new pre-built binary files for the T3W1 hardware model (a QA bootloader and a Bluetooth development firmware blob) and updates the corresponding SHA-256 hashes in a header file. The change is labeled as a routine chore with no changelog entry. There is no description of why the binaries changed, no source diff, and no security context provided, so it is impossible to tell from this commit alone whether the update fixes a bug, adds a feature, or changes security behavior.

This commit only changes the on-screen message shown during firmware installation. If the update is happening over Bluetooth (BLE), the device now tells the user to keep the Trezor close to the host device; if it is happening over USB, it continues to tell the user not to disconnect the cable. There is no change to security logic, cryptography, or data handling.

This commit fixes how the Trezor hardware wallet's Bluetooth Low Energy (BLE) connection settings are changed. It adds a mutex (a kind of traffic light) around code that updates BLE connection parameters, and moves two update calls so they happen only after the connection is safely recorded. Without the mutex, two pieces of code could try to change the connection settings at the same time, which on this Nordic BLE stack can cause the update request to fail or behave unpredictably. The commit message does not call this a security fix, but race conditions in connection management can in principle be abused to disrupt or confuse the BLE link.

This commit tweaks Bluetooth Low Energy timing settings in Trezor's Nordic firmware so the device communicates more frequently with a paired phone or computer. The stated goal is faster reaction times, not a security fix. There is no direct evidence in the commit that this resolves an exploitable vulnerability.

This commit changes the Trezor hardware wallet firmware so that when it receives messages over Bluetooth, it resets the auto-lock timer. This prevents the device from locking itself during long user interactions that happen wirelessly. It is a usability fix, not a vulnerability fix, and does not appear to introduce a security weakness.

This commit is a code cleanup that merges two very similar on-screen keyboards in the Trezor firmware into a single shared component. It does not add new features, change security behavior, or fix a bug. The passphrase keyboard and the label keyboard now share one generic 'StringKeyboard' implementation, with separate input logic for passphrases and labels. Test helpers were updated to recognize the new component name.