BitBox02 firmware

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.

This commit only adds Apache-2.0 license header comments to 16 source files that were missing them. It makes no functional changes to the BitBox02 firmware or its Python tools. There is no security impact.

This commit is a bulk license-header cleanup. It replaces long, multi-line copyright and Apache-2.0 license notices at the top of 429 source files with a single, standardized machine-readable tag: 'SPDX-License-Identifier: Apache-2.0'. No program logic, build rules, or file contents other than the header comments were changed. It does not introduce or fix any security vulnerability.

This commit is a routine code-style fix. It updates the Python formatter (black) configuration so the linter uses the correct pyproject.toml file, and reformats two Python files to match the new style rules. There are no security changes to the firmware or any sensitive logic.

This commit only fixes a typo in a code comment (docstring). It changes the description of when a function can return an error, matching the fact that the function now receives the private key directly rather than fetching it from a locked keystore. No actual code behavior is changed.

This commit is a routine code cleanup. It removes a locally defined constant for compressed secp256k1 public key size (33 bytes) and replaces it with an equivalent constant already provided by the upstream Rust bitcoin/secp256k1 library. The numeric value and behavior remain exactly the same.

This is a small internal cleanup in the BitBox02 firmware's on-screen text input component. A helper function that fetches BIP39 seed words was simplified so callers no longer check its return value; the helper itself now aborts on failure. There is no security vulnerability here—just a minor code-style refactor that keeps the same failure behavior.

This commit removes an old C source file called keystore.c and moves two small cryptographic helper functions directly into the Rust part of the project. The functions themselves still do exactly the same secp256k1 signing and nonce-commitment work as before; they are just called from Rust instead of going through a thin C wrapper. There is no indication this fixes or introduces a security bug.

This commit simply moves a helper function that looks up a BIP39 word by its index from one source file to another. The function's behavior and the callers' logic are unchanged; it is a code cleanup with no security impact.

This commit is a simple code reorganization: it moves functions that perform secp256k1 cryptographic signing from a file named keystore.rs into a file named secp256k1.rs. The actual behavior of the code, including how private keys are used and how signatures are produced, does not change. It is a refactoring, not a security fix or vulnerability.

This commit only updates user documentation (README) and adds a binary firmware file. There is no code change that fixes or introduces a security vulnerability. It is a routine documentation improvement.

This commit updates the Rust compiler toolchain from an unspecified earlier version to Rust 1.92 for the BitBox02 hardware wallet firmware. It also refreshes many vendored third-party Rust libraries (such as libc, hashbrown, getopts) and build tools (cbindgen, bindgen). The stated reason is compatibility with the new toolchain, including a breaking change around panic handling. There is no direct evidence in the commit that this fixes a known security vulnerability, but toolchain and dependency updates can affect security-relevant behavior such as memory safety, panic handling, and type definitions used in cryptographic code.

This commit adds unit tests for two cryptographic helper functions and slightly reorders their internal steps so the output buffer is only written after the HMAC calculation is complete. The change makes it safe for the output buffer to overlap with the input or key buffers, and documents that overlap is allowed. There is no new vulnerability here; it is a defensive hardening and testing improvement.