Trezor firmware

This commit adds support for a new Ethereum transaction type called EIP-7702 (smart accounts / account abstraction) to Trezor firmware. It is a feature addition, not a security fix. The change includes new user-facing confirmation text, test fixtures, and logic to allow signing these transactions only when safety checks are disabled and the destination address is a known allowed contract.

This commit refactors the way digital signatures are encoded and decoded in the Trezor firmware's Python code. It replaces a generic low-level DER sequence encoder/decoder with two dedicated functions for signatures. The change is described by the developer as a cleanup ('chore') with no changelog entry. There is no direct evidence in the commit that this fixes a security vulnerability, but centralizing signature handling can reduce the risk of future mistakes.

This commit simply removes an unused developer convenience command from the build Makefile. It does not change any firmware code, crypto logic, or device behavior, and has no security relevance.

This commit only changes how certain software tests are skipped or run. It replaces manual 'if' checks at the bottom of test files with Python's built-in '@unittest.skipUnless' decorator on test classes. This makes the test suite behave more consistently but does not change any actual product code that users interact with.

This commit is a routine internal cleanup in the Trezor firmware. It moves the SLIP21 path validation into its own helper method, adds a new function to convert SLIP21 paths to human-readable strings, and updates tests. There is no indication it fixes a security vulnerability or changes user-visible behavior in a risky way.

This commit fixes a mismatch in Trezor's Bitcoin Cash address encoding. Previously, the encoder could create addresses with an overly long human-readable prefix (the part before the colon, like 'bitcoincash') that the decoder would later reject as invalid. The patch adds a length check so the encoder refuses to produce addresses that cannot be decoded. It also renames variables and updates comments for clarity, with no functional changes beyond the new length check.

This commit is a straightforward internal code cleanup in the Trezor firmware's user-interface code. It replaces a loose pair of values (a notification text string plus a separate numeric 'level') with a single structured 'Notification' type, and gives the numeric levels named constants like ALERT, WARNING, INFO, and SUCCESS. There is no change to security behavior, no bug fix, and no externally visible functional change for users.

This commit is a routine version bump for Trezor firmware and related embedded components. It only changes version numbers in header files and translation metadata. There are no code changes, no bug fixes, and no security-related modifications visible in the diff.

This change removes a safety check in Trezor's Ethereum staking transaction handling. Previously, the device refused to sign staking/unstaking transactions unless a 'source' parameter was exactly 1 (Trezor's identifier). Now it accepts any source value. This is described by the vendor as a feature to allow staking calls regardless of source, but it weakens a validation gate that helped ensure the transaction was intended for Trezor's staking flow. The change is intentional and documented, but it reduces the device's ability to reject potentially mismatched or unexpected staking contract calls based on source identifier.

This commit fixes a timing side-channel flaw in how Trezor hardware wallets convert a user's recovery phrase (BIP-39 mnemonic words) into secret seed bits. The old code used a fast but variable-time binary search over the word list, which could let a local attacker with precise timing measurements learn information about the recovery words. The patch replaces it with a constant-time linear comparison and also removes an extra integrity check in older (legacy) Trezor firmware to reduce how often the secret seed is processed.

This commit is a routine version bump from 2.10.0 to 2.10.1 in the Trezor firmware repository. It only changes version numbers in a header file and translation metadata, plus updates the signed translation package timestamp and fingerprint. There are no code behavior changes and no security relevance.

This commit only updates the changelog and release notes for Trezor legacy firmware version 1.14.0. It deletes six small draft changelog files and adds their contents to the main CHANGELOG.md. No actual code, logic, or security behavior is changed in this commit.

This commit only changes version numbers and release metadata. It bumps the firmware version from 2.9.7 to 2.10.0 and updates related changelog entries and translation package signatures. The commit message mentions that a separate security fix forced the version bump, but this commit itself does not contain any code fix.

This is a one-line bug fix in a Trezor hardware wallet factory/production testing tool. The function `prodtest_tropic_get_access_credential()` now jumps to cleanup code when it fails to retrieve a public key, instead of continuing to run as if nothing went wrong. Without the fix, the tool could keep processing and potentially leak or mishandle sensitive key material after an error. The affected code is in a production-test (manufacturing) program, not the main wallet firmware users interact with.

This commit adds support for showing clear, human-readable details when signing a Shasta testnet USDT token transfer on the Tron blockchain. Previously, such transactions were displayed as opaque smart-contract data. The change borrows parsing logic from the Ethereum app and hardcodes one testnet token address. It is a feature addition, not a fix for an active vulnerability, though it reduces the chance a user accidentally approves a misleading token transaction.

This commit only adds new message definitions for reading out device telemetry (battery temperature extremes and battery error flags). It does not include any firmware logic that actually collects or responds to these messages, so it cannot by itself be used to attack a device. It is essentially plumbing for a future feature.

This commit adds a new read-only feature that lets the host computer ask a Trezor device for internal telemetry records: minimum/maximum temperature and battery error counts. It is a feature addition, not a fix. There is no direct evidence in the commit that this introduces a security vulnerability, but it does expose previously internal device data over the USB/Protobuf interface. The security relevance depends on whether the new TelemetryGet message is protected by an existing session/access policy or can be requested by any connected host.

This is a routine feature addition to Trezor's cryptographic library. It adds helper functions for comparing DER-encoded data items and reading an item with an expected tag, plus a constant for OID tags and minor const-correctness cleanups. There is no indication of a security bug being fixed.

This commit adds a new internal API surface called 'coreapp API' that lets the core firmware expose a small set of system services (timers, events, debug console, IPC, and shutdown helpers) to a separate 'coreapp' component. It is only enabled for the T3W1 model and is guarded by an 'app_loading' build feature. The change is architectural: it wires a function-pointer getter into the vector table and stores it in the coreapp header so the coreapp can request versioned API tables. There is no direct evidence in the commit of a vulnerability, exploit, or security fix; it appears to be a feature introduction for future app-loading support.

This commit changes a single internal constant so the device can keep track of one extra background process when the optional app-loading feature is enabled. By itself it does not look like a security fix or vulnerability; it appears to be a straightforward capacity increase for a new feature.

This commit adds a brand-new inter-process communication (IPC) subsystem to the Trezor firmware kernel. It lets separate software tasks send fixed-size messages to each other through kernel-managed queues, with memory copies that temporarily disable the memory-protection unit on STM32 hardware. There is no claim in the commit that this fixes a security bug; it appears to be a new feature. The code includes access checks (verifiers) for the user-space syscall path, but because this is a new and complex kernel mechanism, any mistakes in the queue logic or memory copying could become security issues in the future.

This commit adds a new build-time switch called EXTAPP_SUPPORT. When turned off (the default), it prevents the 'app_loading' feature from being compiled into firmware for the T3W1 model. This is purely a build-system/configuration change and does not alter runtime behavior, fix a bug, or change any security-critical code path on its own.

This commit adds a new MicroPython module called `trezorapp` that lets Python code create, write, finalize, and run third-party application images inside the Trezor firmware. It is a feature implementation rather than a bug fix, and there is no direct evidence in the commit that it fixes a security vulnerability. However, because it exposes low-level app loading and task control to Python, any weaknesses in the underlying `app_cache`/`app_loader` C code or in how Python callers use this wrapper could become security-relevant. The commit itself does not describe security relevance, credit a researcher, or acknowledge a vulnerability report.

This is a cosmetic code cleanup. It removes an unnecessary empty keyword-only argument marker from a function signature in documentation and a mock file. There is no functional change to the code that runs on the device.

This commit is a build-system fix for the Trezor firmware. It changes how the Rust static library is added to the linker command in SCons scripts and corrects the relative path to the compiled Rust library. There is no indication in the commit that this fixes a security vulnerability; it appears to be a build correctness or path-fix change.