BitBox02 firmware

This commit swaps one internal cryptographic library for another when computing a special fingerprint used in a backup/recovery feature (BIP-85). The change is described by the developer as a cleanup to use a single, consistent library. There is no direct evidence in the commit that it fixes a security bug or that any vulnerability exists.

This commit is a performance and reliability improvement, not a security fix. It precomputes a wallet's 'root fingerprint' during device unlock and stores it in memory, so the BitBoxApp can read it later without repeatedly asking the secure chip. The secure chip was being throttled by too many rapid requests, which could slow down or temporarily block the device. The change removes that throttling risk and slightly reduces secure-chip wear, but it does not patch an exploitable vulnerability.

This commit is a large internal cleanup of how the BitBox02 firmware's test code and simulator are built. It switches more of the build process to use Rust's standard Cargo tooling, removes a workaround called 'bitbox_merged,' and reorganizes Rust code to avoid circular dependencies. There is no indication this change fixes a security bug or introduces a new security feature.

This commit removes several vendored Rust library dependencies (libc, proc-macro2, quote, syn, unicode-ident) and updates the Cargo.lock file. The stated goal is to reduce dependency count by using the same versions as the Rust standard library. There is no direct code change to the BitBox02 firmware logic, no bug fix, and no security patch visible in the diff.

This commit updates the vendored rust-bitcoin library inside the BitBox02 firmware from version 0.32.2 to 0.32.7. It is a routine dependency refresh that pulls in several upstream bug fixes and small feature additions, such as support for testnet4 and pay-to-anchor outputs. The commit does not describe itself as a security fix, and the visible changes are mostly API cleanups and correctness improvements rather than patches for an active vulnerability.

This commit rewrites a Bitcoin Schnorr signing function from C to Rust. It is a routine refactoring/porting change with no obvious security bug. The new Rust code does the same steps as the old C code: derive a private key, optionally tweak it, sign with a random auxiliary value, and return the signature. The old C implementation also verified the signature internally after signing; that post-sign verification step is removed in the Rust port, but the commit includes unit tests that verify produced signatures are valid.

This commit upgrades the Rust code edition from 2021 to 2024 across the project and applies the matching rustfmt formatting. It is a routine toolchain/language-version migration: Cargo.toml files are updated, import order is re-sorted, unsafe blocks are wrapped in new unsafe extern/unsafe {} syntax required by the 2024 edition, and test code is reformatted. There are no functional security fixes or behavior changes visible in the diff.

This commit updates a vendored Rust library used for deriving cryptocurrency keys (bip32-ed25519) from version 0.2.0 to 0.2.1. The visible code changes are mostly housekeeping: updating Rust edition, formatting, and explicitly zeroing out sensitive key data when dropped. There is no direct evidence in the commit message or diff of a security vulnerability being fixed, but updating a cryptographic dependency can sometimes include undisclosed fixes.

This commit swaps out an internal cryptographic library dependency. The firmware previously used a library called libwally-core, which bundled a special version of the secp256k1 elliptic-curve code. The change removes libwally-core and uses secp256k1-zkp directly. This is a build-system and dependency refactor, not a fix for a known attack. It slightly reduces firmware size and changes how the code is compiled and linked. There is no direct evidence in the commit that this resolves a security vulnerability, but any change to core crypto code carries a small risk that build settings could alter behavior.

This commit only changes a unit test file. It swaps one way of getting a test private key (from an older C library called libwally) for another way (from the project's newer Rust code). The actual device firmware and security logic are not changed. There is no indication this fixes or introduces a security bug.

This commit is a small internal cleanup in the BitBox02 hardware wallet firmware. It changes how the code passes the cryptographic context (specifically for secp256k1 elliptic-curve operations) from using a shared context provided by an older library (libwally) to using a Rust-managed context. The functions themselves and the underlying cryptographic operations remain the same. There is no direct evidence in the commit that this fixes an exploitable security vulnerability.

This commit is a performance optimization for the BitBox02 hardware wallet firmware. It replaces repeated creation and destruction of a cryptographic context (used for Bitcoin's secp256k1 elliptic-curve operations) with a single global context that is initialized once and reused. There is no indication in the commit that this fixes a security vulnerability; it is described purely as an efficiency improvement.

This commit is a pure refactoring: it renames the test-only 'hardware-mocks' directory and all related function names to 'hardware-fakes' across build files, source code, and unit tests. No production firmware behavior changes, no security fixes, and no vulnerability is introduced or patched.

This commit is a pure internal test-code refactor. It moves CMocka-specific mock functions out of a shared hardware-mocks library and into the unit-test directory so that the simulator no longer depends on the CMocka testing framework. No production firmware code is changed, and nothing in the commit affects the security of the shipped BitBox02 device.

This commit is a large but purely organizational change: it moves all vendored (third-party) Rust dependencies from the `src` directory to a new `external/vendor` directory. Only two small configuration files were actually modified: `.cargo/config.toml` (to point Cargo at the new vendor directory) and `external/vendor-rust.sh` (a helper script). The millions of added and removed lines are just the same dependency files being relocated, not new code. There is no visible change to the firmware's behavior or security logic.

This commit is a routine code cleanup in the BitBox02 hardware wallet firmware. It removes an old wrapper around a C-language SHA-512 function and switches the Rust code to use a pure-Rust SHA-512 implementation from the `bitcoin::hashes` library. It also removes an unused feature flag and simplifies dependencies. There is no direct evidence in the commit that this fixes a security vulnerability.

This commit swaps the cryptographic hashing and HMAC functions used throughout the BitBox02 firmware from the libwally library to equivalent Rust implementations. The goal is to remove the libwally dependency. The change touches sensitive code paths such as seed stretching, U2F key generation, and secure-chip authorization, but the commit itself does not claim to fix any security bug. The main risk is that any subtle difference in behavior between the old and new implementations could affect how keys are derived or how the device authenticates, though the diff shows no obvious vulnerability.

This commit updates the BitBox02 firmware's Rust code to use Rust's built-in C type definitions instead of a custom module. The commit message notes a bug: the custom module incorrectly defined 'unsigned int' as 64 bits on 64-bit systems, when it should always be 32 bits. The change removes the buggy custom type definitions and switches to the standard Rust core::ffi types. This is primarily a code-quality and correctness fix, but the wrong type sizes could have caused subtle memory or interface mismatches between Rust and C code, especially during testing on 64-bit computers.

This is a tiny build-configuration fix for a specific BitBox02 hardware variant (the 'BitBox02 Plus' platform used in Nova bootloaders). The change removes two optional Rust dependencies that were accidentally enabled for that platform. The commit message says those dependencies are not needed there. There is no direct evidence in the commit of a security vulnerability; it looks like a cleanup to avoid compiling unnecessary code in the bootloader.

This commit simply moves a helper function that looks up a BIP39 word by its index from one Rust module to another. The code itself is unchanged, and there is no indication of a security fix or vulnerability.

This commit replaces the BIP39 (seed phrase) implementation inside the BitBox02 hardware wallet from one library (libwally-core) to another (rust-bip39). The main user-visible reason is speed: unlocking the device is now faster, so the unlock animation was shortened. The change touches how seed phrases are converted to cryptographic seeds and how individual BIP39 words are looked up. There is no direct evidence in the commit that this fixes a known security bug, but any change to cryptographic code can introduce subtle risks, so it deserves careful review.

This commit rewrites a small part of the BitBox02 U2F feature from C to Rust. When you register or authenticate with an unknown website, the device shows a short mnemonic phrase instead of a site name. The change swaps the old libwally BIP39 library for the Rust bip39 crate to generate that phrase. It is a routine refactoring/porting change; there is no direct evidence it fixes or introduces a security vulnerability, though any rewrite can carry subtle bugs.

This commit adds a new software library (a BIP-39 implementation for handling recovery seed phrases) to the BitBox02 firmware and stores a copy of it inside the project's source tree (vendoring). It does not change any device behavior by itself; it is purely a dependency addition. There is no direct evidence in the commit of a security vulnerability, but adding a new dependency always slightly increases the attack surface and supply-chain risk.

This commit is a pure test-infrastructure refactoring. It merges duplicate mock and fake hardware-implementation files that previously existed separately for unit tests and the simulator into a single shared library called 'hardware-mocks'. It also adjusts Rust build flags so RTT logging only compiles for the real firmware target (target_os='none'). There is no change to the actual device firmware or to any security-critical runtime behavior.

This commit is a routine code cleanup that turns the screen drawing code into a generic interface so the same code can run on both the real device and a software simulator. It does not fix or introduce any security issue.