Trezor firmware

This commit only updates a bundled cryptographic library (secp256k1-zkp) from version 0.7.0 to 0.7.1. The actual code change is a one-line update to the submodule pointer. The commit message does not describe any security fix, and no security-relevant details are visible in the diff itself.

This commit removes a single line from the project's Git submodule configuration. It stops pinning the libtropic submodule to the 'develop' branch, meaning the project will now use the submodule's default branch (likely 'main' or 'master'). There is no code change, no bug fix, and no direct security issue visible in the diff itself.

This is a hardening change for the random number generator inside Trezor hardware wallets. It makes sure that temporary memory holding secret random values from the Optiga and Tropic security chips is wiped immediately after use, rather than only once at the end. It also fixes a subtle edge case where a buggy Tropic chip call could leave old Optiga randomness in the temporary buffer, potentially weakening the final random output.

This commit adds a new Rust-based on-screen menu component for the Trezor hardware wallet's Bolt user interface. It is a straightforward feature implementation and does not fix or introduce any obvious security issue. The component is not yet wired into any user-facing flows.

This commit only changes the data format definitions (protobuf messages) used to talk to a Trezor hardware wallet. It adds new optional fields for an upcoming Ethereum feature called EIP-7702, which lets an account temporarily act like a smart contract. The commit does not contain any actual signing logic, user confirmation screens, or security checks. Because it is just a protocol definition update, it does not by itself create a vulnerability, but it is a building block for future code that will handle these authorizations.

This commit only changes test data and expected screen fingerprints for Trezor's Ethereum EIP-7702 signing tests. It replaces one test case that used a nonce of 0 with the same scenario using a nonce of 67, because the real-world protocol rule requires the tuple nonce to be non-zero. No production firmware code is modified, so this commit does not fix or introduce a security vulnerability in shipped devices.

This commit adds a progress bar feature for firmware updates sent to the nRF wireless chip inside Trezor devices. It threads a callback function through the upload code so the bootloader can show how much of the image has been transferred. The existing public syscall entry point is deliberately left unchanged, so normal app behavior is unaffected. There is no security fix or vulnerability here.

This commit only adds a plain-English comment explaining an existing function that estimates how long a random-number generation call takes. No code behavior changed, and nothing was fixed or added that affects security.

This commit adds compile-time guards to prevent an intentionally insecure random-number generator from being accidentally included in firmware that runs directly on Trezor hardware. It does not fix an active bug, but it adds safety rails so a future build misconfiguration cannot silently ship weak randomness to real devices.

This commit is a routine build cleanup. It moves a header file to the correct folder and updates two source files to include it from the new location. There is no security-relevant change here.

This commit is a straightforward internal code reorganization. It moves several low-level hardware communication modules (NRF radio, SMP firmware-update protocol, IRQ utilities, and C-string helpers) into different Rust crates so the project structure is cleaner. No security vulnerability is introduced or fixed; it is purely a refactoring change.

This commit is a build-system cleanup for the Trezor firmware's Rust code. It changes how the 'emulator' feature flag is passed between different software components. The firmware project no longer supports the emulator feature (which makes sense because real firmware runs on hardware, not an emulator), while the bootloader, prodtest, and core Rust library now propagate the feature more consistently. There is no indication of a security vulnerability in this change.

This commit fixes how the Trezor emulator initializes its 'monotonic counters'—security counters that only ever increase and are used to prevent downgrades to older, possibly vulnerable firmware. Before this fix, the emulator did not explicitly initialize these counters before running the boot emulator, which could lead to uninitialized or incorrect counter values during emulator-based testing. The fix adds a dedicated initialization routine and calls it in every relevant firmware component. On real hardware the initialization is currently a no-op, so this primarily affects the Unix/emulator build used for development and testing.

This commit fixes a bug in Trezor's AES encryption/decryption code where a negative length value could be passed to low-level AES functions. Previously, those functions treated the signed length as a large unsigned number, which could cause them to read or write far beyond the intended memory buffer. The patch makes every AES mode reject negative lengths and adds error handling so callers fail safely instead of silently producing bad results or touching memory they shouldn't.

This commit simply moves the list of contributors from two places (a package metadata file and the README) into a single dedicated AUTHORS file. It is a routine housekeeping change with no security relevance.

This commit is a small internal cleanup in Trezor's Ethereum signing code. It changes how two special 'magic' bytes (the transaction type markers for newer Ethereum transaction formats) are fed into the cryptographic hash. Previously the code used the general RLP encoder to write the single-byte marker; now it appends the raw byte directly. The commit message says this avoids relying on the assumption that RLP encodes small integers as a single byte. There is no direct evidence in the commit or supplied references that this fixes an exploitable vulnerability, but it removes a fragile assumption in security-critical hashing code.

This commit only adds a new unit test to the Trezor firmware codebase. It verifies that very short Ethereum RLP-encoded byte strings and small positive integers encode to themselves, which is a known property of the RLP specification. No production code was changed, and there is no security fix or vulnerability present in the diff.

This commit removes the SHA-1 hashing function from the regular Trezor firmware. SHA-1 is an old, weak hash algorithm that is no longer considered secure for sensitive uses. The change deletes the code that exposes SHA-1 to apps running on the device, along with related tests and benchmarks. It is a hardening/cleanup change rather than a fix for an active bug or exploit.

This commit fixes three places in the Trezor firmware's cryptographic code where a memory-clearing function could be called with a NULL pointer. In practice, passing NULL to memzero is harmless on Trezor's platform (it does nothing), but it is undefined behavior in C and could cause a crash or unpredictable results on other systems. The change adds simple NULL checks before clearing plaintext output and before wiping responder/initiator objects during cleanup.

This commit is a code cleanup (refactor) for the cryptographic handshake code used in Trezor devices. It changes how the other party's long-term public key is returned to the caller: instead of storing it inside an internal state structure, the function now writes it into a buffer supplied by the caller. The commit message explicitly calls it a refactor and includes '[no changelog]', indicating it is not being presented as a security fix. There is no direct evidence in the diff that this change fixes an active vulnerability, but it does reduce the amount of sensitive key material kept in internal state and gives callers explicit control over the output buffer, which is generally a defensive improvement.

This commit simply renames two groups of internal status labels (called enums) in the Trezor firmware's cryptographic code. The old names like WAITING_FOR_REQUEST1 were shared between two different parts of the code, so the developer gave them longer, unique names that include which part they belong to. The actual numeric values and program behavior are unchanged. There is no security fix or vulnerability here.

This commit simply reorders the arguments of an internal function called dh() and updates every place that calls it. The actual math and security behavior are unchanged; it is a code cleanup with no security effect.

This commit changes how a cryptographic library sets up secure connections. Previously, the code automatically calculated the public key from the private key. Now, the caller must provide the public key directly. This is a code-quality refactor that reduces the risk of using mismatched keys, but the commit itself does not claim to fix a specific security bug and no exploit is described.

This commit is a build-system refactoring for Trezor firmware. It moves the mapping of command-line build options to Rust/cargo features out of hard-coded Rust logic and into per-project TOML files. It also adds a small change so debug builds automatically enable the 'debug-link' option. There is no direct vulnerability in the diff, but any mistake in the new TOML mappings could accidentally enable or disable security-relevant features in a shipped firmware image.

This commit tightens security for a new Ethereum feature (EIP-7702 account delegation) in Trezor hardware wallets. Previously, the wallet would recognize certain smart-contract delegate addresses on any chain, and would allow signing on unknown chains with only a generic warning. Now it checks that both the chain ID and the delegate address match an approved list, and it refuses to sign on unknown chains entirely. This prevents a malicious app or website from tricking a user into authorizing a delegate on an unexpected network.