BitBox02 firmware

This commit is purely a test-suite update for the BitBox02 hardware wallet's Ethereum transaction signing. It adds unit tests that verify the new 'streaming' mode for large transaction data produces the same cryptographic signatures as the older non-streaming mode, and updates test data files. There is no change to production firmware code or user-facing behavior, and nothing in the commit suggests a security vulnerability.

This commit adds new message definitions and generated code to support streaming large Ethereum transaction data in chunks, but it does not implement the actual streaming logic. Existing tests are updated only to include the new optional field set to zero, meaning the current behavior is unchanged. There is no indication this is a security fix or introduces a vulnerability.

This commit is a pure code reorganization: it moves the BitBox02-specific hardware abstraction layer (HAL) implementation out of one large file into several smaller files in a new submodule. No functionality, behavior, or security properties of the firmware appear to change. It is comparable to rearranging chapters in a book without rewriting the text.

This commit is a simple code reorganization: it takes several related pieces of a hardware abstraction layer (HAL) that were all written in one large file and splits them into smaller, separate files. No behavior of the device or its security functions was changed. It is comparable to moving chapters of a book into individual files without rewriting the text.

This commit is a simple internal cleanup in the BitBox02 firmware's Rust code. It removes a shortcut (a 're-export') that made test-only user-interface helpers available under an old module path, and updates all test files to import those helpers directly from their new location. There is no change to the actual device behavior, no bug fix, and no security impact.

This commit is a pure internal code reorganization (refactor) of the BitBox02 firmware's Rust code. It moves the user-interface trait and its real/testing implementations into a new 'hal' (hardware abstraction layer) module structure and renames some types (e.g., Workflows -> Ui, RealWorkflows -> BitBox02Ui, TestingWorkflows -> TestingUi). No security-sensitive behavior appears to change; it is a maintainability/clean-up change.

This commit rewrites the BitBox02 hardware wallet's main firmware loop from C to Rust. It is a large refactoring change that moves core USB, Bluetooth/UART, and workflow handling into Rust. The change itself is not a security fix and does not introduce an obvious vulnerability in the diff, but any rewrite of security-critical firmware code carries a risk of subtle behavioral differences or memory-safety edge cases at the C/Rust boundary. The commit message and diff do not describe any security issue or credit a researcher.

This commit removes an empty placeholder function called hww_process() that did nothing. It is a routine code cleanup with no security relevance.

This commit is a build-system refactor: it moves the FatFs microSD filesystem library from a direct CMake target into a new Rust crate wrapper, and makes sure C compiler hardening flags (such as stack-protector) are also applied when Cargo's build.rs scripts compile C code. There is no obvious runtime vulnerability in the diff, but the change touches how security-relevant C code is compiled, so it deserves a quick sanity check that the new wrapper preserves the same flags and symbol visibility.

This commit turns on a stricter compiler warning that catches risky pointer casts in C code, and fixes the resulting warnings. The changes replace direct casts from byte buffers to larger types (like treating a raw byte array as a 32-bit number or USB frame) with safer memcpy-based copies. The commit message explicitly frames these as classes of undefined behavior (alignment and strict-aliasing issues) that could lead to miscompilation or incorrect reads. It is a hardening/correctness patch rather than a fix for a known exploitable bug, but the affected code paths include bootloader pairing-code handling, firmware version parsing, USB packet processing, and BLE pairing-code display.

This is a small code cleanup change. A function that sends the device's Bluetooth name to a wireless chip is simplified by removing an unnecessary length parameter. The function now figures out the string length itself using strlen(), which is exactly what every caller was already doing. There is no security issue visible in this change.

This commit is a minor code cleanup in the BitBox02 firmware's Rust wrapper around secp256k1 cryptography. It removes temporary variables that held function return values and instead checks those return values directly inside 'if' conditions. There is no change to program logic, no security fix, and no new vulnerability.

This commit is a small code cleanup in the BitBox02 firmware's Rust code. It replaces runtime hex decoding with a compile-time macro for test data only. There is no security vulnerability here—just a dependency swap that makes unit tests slightly more efficient and removes an unused dev-dependency.

This commit hides a special testing-only function from the normal firmware build. The function itself is not a vulnerability; it is a build-hygiene change to make sure code meant only for unit tests is not compiled into the real device firmware. That reduces the attack surface slightly, but it does not fix any known bug.

This commit removes a duplicate low-level binding to a secp256k1 cryptographic function and replaces its use with an equivalent, already-vetted wrapper from the project's dependency on the bitcoin::secp256k1 Rust crate. It is a code cleanup/refactoring change with no security-relevant behavior change visible in the diff.

This commit is a build-system refactor: it moves the secp256k1 cryptographic library dependency into a new Rust crate called bitbox-secp256k1 so it can be built with normal Cargo tooling instead of CMake. The actual cryptographic functions (signing, nonce commitments, DLEQ proofs, etc.) are copied almost unchanged from existing modules into the new crate. There is no direct evidence in the commit that this fixes a security vulnerability or introduces a new exploit.

This commit rewrites a small piece of the BitBox02 factory-setup code from C to Rust. The code verifies a cryptographic signature on the device during factory setup. The change itself is a routine refactoring: it removes the old C secp256k1 library call and replaces it with an equivalent Rust call. There is no indication in the commit that this fixes a known security bug, and the new Rust code includes tests for invalid inputs. On its own, this looks like a defensive hardening/cleanup change rather than a vulnerability fix.

This commit is a straightforward internal refactoring: it moves the device-reboot-into-bootloader function behind a new 'System' hardware-abstraction trait so the rest of the Rust code calls it through a generic interface rather than directly. The actual reboot behavior, safety checks (a user confirmation screen), and underlying C function are unchanged. There is no new vulnerability here; it is normal code cleanup.

This commit rewrites a small piece of firmware logic from C to Rust. The logic decides whether the BitBox02 Nova hardware wallet should use Bluetooth or USB for communication. There is no obvious security bug introduced by the change; it appears to be a routine language port with matching behavior and added unit tests.

This commit updates the BitBox02 firmware's vendored copy of the Rust 'miniscript' library to version 13.0.0, along with its dependency 'hex-conservative'. The stated reason is to reduce firmware size by about 30 KB. The change is a routine dependency refresh; the commit message and diff do not describe any security bug being fixed, and no independent security advisory is supplied.

This commit is a routine release packaging update. It adds the signed build reproducibility assertions for BitBox02 firmware version 9.25.0 (both the multi-coin and Bitcoin-only variants) and updates the helper script and documentation to handle a new naming scheme where the product name is included in the assertion filename. There is no code change to the firmware itself and no security vulnerability is introduced or fixed.

This commit only fixes the formatting of license headers in automatically generated Python type-stub files. It moves the SPDX license notice from a standalone comment line into the generated docstring block. There is no change to program logic, no security fix, and no vulnerability.

This commit simply moves a set of helper functions for handling strings from one Rust module to another. The actual code is copied unchanged, and all existing callers are updated to use the new location. There is no security fix or behavior change.

This commit adds a new read-only field to the BitBox02's device information API that tells the connected app which password-stretching algorithm the device uses. It does not change how passwords are stretched or how they are verified; it only exposes existing internal information to the host. There is no indication this is a security fix or that it introduces a vulnerability.

This commit is a code cleanup and test-improvement change. It moves two device-attestation helper functions from a direct hardware call into a software 'hardware abstraction layer' (HAL) so the code can be tested without the real device. It also adds unit tests that simulate the attestation process. There is no indication this fixes a security bug or introduces a new vulnerability.