Trezor firmware

This commit is a test-infrastructure cleanup. It moves JavaScript code out of HTML files into a shared external file, bundles the pixelmatch image-comparison library locally instead of loading it from a CDN, and makes the UI test reports wait for images to finish loading before comparing them. There is no security-relevant change to the Trezor firmware or wallet behavior.

A function that reads firmware image headers was returning the wrong kind of error value. In C, returning a special 'false' value where a pointer is expected can confuse the rest of the program, potentially causing crashes or allowing a malformed firmware image to be treated as valid. The patch makes all error paths consistently return NULL, which is the normal 'no valid header' indicator for this function.

This commit adjusts how the Trezor bootloader's length is calculated and pads the bootloader image to a 512-byte boundary. The old calculation added the sizes of two memory sections, which could produce a value that does not match the actual padded image size. The new calculation uses a dedicated end marker, and the linker script now explicitly fills unused space with zeros and aligns the image. This is a defensive fix in low-level firmware packaging; it does not by itself show an exploitable bug, but misaligned or incorrectly reported bootloader sizes could theoretically cause verification or update failures.

This commit fixes the horizontal centering of a small vendor logo shown on the bootloader's 'unsafe firmware' warning screen. The old code subtracted 22 pixels from the screen width before dividing by two, which would slightly offset the 24x24 image. The new code simply centers the image using the screen's midpoint. There is no security-relevant change in the diff itself.

This commit improves error messages and logging in a Trezor production-test command file for the Tropic chip. It does not change program logic, access controls, or cryptographic checks; it only makes failures easier to diagnose by printing the actual numeric error code and correcting a misleading function name in one message. The change is in a prodtest (factory testing) tool, not in the wallet firmware that end users rely on for securing funds.

This commit simply moves an internal header file inclusion from one place to another. It is a routine code organization change with no visible security effect.

This commit only adds a new error code constant named TS_ENOINIT ('Not initialized') to a header file. It does not change any runtime behavior, fix a bug, or alter how the device handles errors. There is no security relevance visible in the change itself.

This commit only changes a test helper file. It adds a clearer error message when test emulators haven't been downloaded yet. It does not touch the actual Trezor firmware, wallet code, or any user-facing security behavior.

This commit only updates two documentation files. It changes the URL path for emulator download fixtures and clarifies that users should specify a device model when running the download script. There is no code change and no security relevance.

This commit only changes internal test scripts used to download Trezor firmware emulators for testing. It does not modify the actual device firmware, wallet logic, cryptography, or any code that end users rely on. There is no security issue visible in the change.

This commit is a routine internal CI (Continuous Integration) maintenance change. It updates two GitHub workflow files so that a script which downloads old Trezor emulators for upgrade testing receives the correct device model parameter. There is no change to the firmware code that runs on user devices, no change to cryptographic operations, and no indication of any security bug being fixed.

This commit only changes the test suite and supporting Python tooling. It renames a model set from TREZORS to ALL_MODELS, splits devices into legacy and core groups, and updates upgrade tests so they can run against individual Trezor models rather than just broad 'legacy' or 'core' categories. There is no change to the firmware that runs on the hardware wallet, no fix for a security bug, and no new attack path.

This commit removes an unused data field called language_data_length from the RebootToBootloader command used during Trezor firmware updates. It is a cleanup change that marks the old field as reserved in the protocol definition and regenerates the corresponding code in Python, Rust, and the device firmware. There is no security-relevant change here.

This commit simply removes a five-line comment block that labeled some older code as deprecated and planned for removal. No actual code behavior changed, and no security issue is present in the diff.

This commit removes a feature that let a firmware update package include a language translation file. It is a routine cleanup: the device will no longer accept or install a language blob while rebooting into bootloader mode for a firmware update. There is no indication this fixes a security bug or introduces a vulnerability.

This commit removes a feature from Trezor's Python tools that let users upload a language translation file during a firmware update. It is a routine cleanup (chore) that deprecates the language-blob upload option and simplifies the code. There is no indication of a security fix or vulnerability.

This commit only adds expected screenshot fingerprints (test fixtures) for a newly added automated test. It does not change any firmware code, wallet behavior, or user-facing functionality, so it has no security relevance on its own.

This commit loosens address-path validation for older Trezor (legacy) devices when signing Ethereum-style transactions. Previously, only non-standard networks could use Ethereum's mainnet derivation path; now any network except Ethereum mainnet itself can do so, and Ethereum mainnet additionally accepts testnet-style paths. The stated purpose is to support newer networks like Hyperliquid that cannot get an official coin-type registration. The change is a deliberate feature backport, not a covert bug fix, but it does relax a security-relevant boundary that normally prevents cross-network address reuse.

This commit only adds a new automated test to the Trezor firmware test suite. It checks that a non-Ethereum network can still use the standard Ethereum account derivation path when signing a transaction. No product code was changed, so this cannot introduce a security vulnerability or fix one in the firmware itself.

This commit is a routine version bump from 2.9.8 to 2.10.1 for the Trezor firmware. It only changes the version number in one header file and updates the matching version numbers in translation files, plus refreshes the translation signature metadata. There are no code behavior changes, no bug fixes, and no security-related modifications.

This commit adds the ability to sign native TRON (TRX) transfers on Trezor hardware wallets. It introduces new message types, a signing workflow, user confirmation screens, and client-side helpers. The change is a feature addition rather than a fix for a known vulnerability, and there is no vendor statement that this resolves a security issue.

This is a routine build-system update that bumps the recorded version of an internal vendor package (tvl) from 2.2 to 2.3 in the Python lock file (uv.lock). The change itself is a single digit in a metadata file and contains no executable code changes, no security fixes, and no disclosed security relevance.

This is a one-line build script change that adds the '--locked' flag to a Python package manager command. It tells the build tool to refuse to proceed if its lock file is out of date, preventing accidental use of unexpected dependency versions. There is no security vulnerability or exploit here.

This is a small debugging improvement for Trezor's Rust firmware code. It changes panic error messages so that, in debug builds, the actual panic message text is shown instead of a generic placeholder 'rs'. There is no security vulnerability or fix here—just better diagnostic output for developers.

This change adjusts how the Trezor firmware's Rust code is built for the debug software emulator. Previously, all builds used a setting that makes the program immediately stop (abort) if a panic occurs. Now, the debug emulator keeps the normal panic mechanism so that internal debug assertions can be reported instead of silently crashing. This is a build/developer-experience change, not a fix for an exploitable security flaw in shipped hardware wallets.