BitBox02 firmware

This commit adds support for deriving and verifying Bitcoin-family destination addresses inside payment-request memos used for coin swaps. It extends the existing Ethereum-only address-derivation feature to also cover BTC/LTC, and validates that the claimed swap destination address actually matches the derived one. There is no direct evidence this fixes an active security bug; it appears to be a feature addition that also hardens validation.

This commit is a routine code cleanup: it removes several C functions that control the Bluetooth chip and replaces their use with equivalent Rust functions. There is no indication in the commit itself that this fixes a security bug or introduces a vulnerability. It is a refactoring change.

This is a routine code cleanup commit that reorganizes how two internal Rust software components connect to each other. It removes a circular dependency where a higher-level crate called 'bitbox02-rust' depended on a lower-level crate called 'bitbox02', and vice versa. The change moves a small piece of noise-cryptography-related code into the lower-level crate and adjusts build configuration files accordingly. There is no indication this fixes a security vulnerability or changes user-visible behavior.

This is a minor Python import cleanup in a developer/test script. It changes how one internal class is imported so that the script works reliably when installed in 'editable' mode. There is no security issue here.

This commit is a routine internal refactoring: it moves the lookup of which secure chip type (ATECC or Optiga) is present from an older C memory module to a newer Rust memory module. The actual chip-detection logic and behavior do not change; only which internal API is called. There is no indication this fixes or introduces a security vulnerability.

This commit is a software architecture cleanup: it moves some type definitions and helper functions so that secure-chip code (ATECC/Optiga) no longer depends directly on the BitBox02-specific memory module. The goal stated by the developer is to make those modules reusable in a future BitBox03. There is no direct evidence in the commit that it fixes a security vulnerability, changes cryptographic behavior, or introduces a bug.

This commit hardens the project's automated CI workflow in two ways: it pins a third-party Mattermost notification action to a specific, unchangeable version (instead of a moving 'master' branch), and it restricts the job's GitHub token permissions to read-only access to repository contents. These are defensive security improvements that reduce supply-chain and privilege risks, but the commit itself does not fix an active vulnerability.

This commit swaps out an old C ringbuffer for a new Rust-based byte queue used to hold data sent to the Bluetooth chip. The change touches many files but is mostly a rewrite/refactor. It removes several explicit 'will it fit?' size checks before adding data to the queue, and it changes how callers pass the queue around. The Rust ByteQueue implementation itself is not shown in the diff, so we cannot verify whether it safely handles overflow, memory allocation failures, or concurrent access. The change is therefore a security-relevant refactor with some risk, but no proven vulnerability is visible in the supplied commit.

This commit adds a new 'coin purchase memo' feature to BitBox02 payment requests. It lets a payment request include details about a separate coin purchase (e.g., '0.25 ETH to address 0x...') and verifies that the listed Ethereum address really belongs to the wallet by deriving it from a provided keypath. The change is mostly a feature addition, but it introduces cross-currency validation logic and a TODO noting that the user-interface confirmation for this new memo type is not yet implemented.

This commit is a routine code reorganization. It moves two constant definitions—how long device names and multisig account names can be—from the C code into Rust, so both the BitBox02 and future BitBox03 products can share the same values. The actual length limits (63 characters plus a null terminator for device names, 30 plus null for multisig names) are unchanged, and the commit adds compile-time checks to prove they stay the same. There is no security bug being fixed here.

This commit only cleans up test code by removing unnecessary calls to a mock memory setup function. It does not change the actual firmware that runs on the BitBox02 device, so it has no security impact on users.

This commit is a straightforward internal code refactor. It introduces a new 'KeystoreHal' adapter so that the keystore code can borrow only the hardware subsystems it needs (memory, random number generator, secure chip) instead of borrowing the entire HAL, which also contains the user interface. The stated reason is to allow a UI animation to run in parallel while the device unlocks. There is no change to security logic, cryptography, or user-facing behavior.

This is a small internal code cleanup in the BitBox02 firmware's Rust code. It changes a helper function so it borrows only the memory/storage part of the hardware abstraction layer, rather than the whole hardware abstraction layer. The commit message says this is preparation for a future change where the user interface part of the hardware layer will be used at the same time during wallet unlocking. There is no direct security fix here and no vulnerability is described.

This commit simply moves a function from one Rust source file to another. The code itself is unchanged; only its location in the project changed. There is no indication of a security fix or vulnerability.

This commit simply moves a function called rust_salt_hash_data from one Rust source file to another. The function itself is unchanged; only its location and the associated test code are reorganized. There is no indication this fixes or introduces a security problem.

This commit is a routine code reorganization. It moves two C-callable Rust functions related to Bluetooth Low Energy (BLE) communication mode from one Rust source file to another, and adjusts which Rust crate features enable the relevant code. There is no visible change to what the code does, only where it lives in the project. No security issue is evident from the diff.

This commit is a straightforward internal code reorganization. It moves the C-compatible entry point for the device's main loop from one Rust module to another, so that the core Rust logic no longer directly depends on the hardware abstraction layer. There is no change to user-facing behavior, no bug fix, and no security-related content.

This commit is a pure internal code reorganization: it moves the BitBox02 hardware-abstraction-layer implementation from one Rust crate (bitbox02-rust) into another (bitbox02). The actual logic, behavior, and security-sensitive operations such as memory access, random number generation, secure-chip handling, SD card access, and user-interface prompts remain identical; only the file paths and import paths change. There is no indication of a security fix or vulnerability being addressed.

This commit is a routine code reorganization: it moves hardware-abstraction trait definitions (interfaces describing how the firmware talks to the screen, secure chip, memory, SD card, random number generator and system reboot) from one internal Rust crate to a newly created crate called bitbox-hal. No behavior of the actual device code is changed; it is purely a dependency and file move to avoid circular imports in the future.

This commit is a routine internal code cleanup. It moves the definitions of confirmation-screen parameters and fonts out of the workflow layer and into the hardware-abstraction (HAL) layer, then updates all call sites to use the new names. There is no change to user-facing behavior, no bug fix, and no security vulnerability being addressed.

This is a routine build-system and toolchain update for the BitBox02 firmware. It adds support for a new ARM processor target (Cortex-M33), upgrades the Rust compiler, LLVM, and the ARM GNU toolchain, and pulls in newer versions of some third-party Rust libraries. There is no direct evidence in the commit of a security vulnerability being fixed or introduced. The main risk is the usual one with large toolchain and dependency updates: a small chance that compiler, library, or behavior changes could introduce subtle bugs, but nothing in the diff points to an exploitable flaw.

This commit adds an optional mode for signing Ethereum typed messages (EIP-712) that skips the anti-klepto protocol, falling back to normal deterministic signatures. The change is intentional and documented: some DeFi apps need signatures that are reproducible by other wallets, which the anti-klepto protocol prevents. The feature is gated behind a new host flag and requires firmware v9.26.0 or newer. It does not remove anti-klepto from other signing paths such as Bitcoin or regular Ethereum transactions.

This commit refactors how random numbers are generated during the backup verification workflow. Previously, the code called a low-level device function directly; now it uses a hardware abstraction layer (HAL) interface so the same code can be tested with a mock random source. The change itself is a code-quality/testability improvement and does not appear to fix an active security vulnerability, but it touches the code that creates the random word-order challenges used to verify a user's seed backup.

This commit adds a new method called mcu_32_bytes to the random number generation abstraction layer in the BitBox02 firmware. It is a straightforward code addition that exposes an existing microcontroller random function through the Rust hardware abstraction layer, and adds corresponding test support. There is no indication this fixes or introduces a security vulnerability.

This commit is a routine internal code cleanup in the BitBox02 firmware's Rust hardware-abstraction layer. It restructures how subsystems (screen UI, random number generator, SD card, secure chip, memory, system control) are accessed so that multiple subsystems can be borrowed at the same time. The stated reason is to let the user-interface code use the random generator for a mnemonic quiz feature. There is no security fix or vulnerability patch here.