BitBox02 firmware

This commit adds a new device API that lets a host computer request up to 20 Bitcoin extended public keys (xpubs) in a single call, instead of making one call per key. The goal is to reduce how often the device talks to its secure chip, avoiding a throttling safeguard. The change itself is a feature addition, not a fix for a known vulnerability, and the code applies existing keypath validation and a double-check against bitflips.

This is a build-system maintenance commit. It updates how the project enables AddressSanitizer and UndefinedBehaviorSanitizer so they work on modern toolchains, bumps the minimum macOS version for compatibility, and adds a CI check to confirm the sanitizer is actually linked into unit tests. There is no indication it fixes a security vulnerability in shipped firmware or in user funds.

This commit fixes a single typo in a code comment (docstring). The example Bitcoin keypath was missing an apostrophe in one place (m/84/0'/0'/0/0 changed to m/84'/0'/0'/0/0). No actual program code was changed, so there is no functional or security impact.

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 adds a new simulator/testing feature that pretends the device is a 'Nova' model. It only touches test and simulator code, not the real firmware that runs on customer hardware. There is no indication of a security bug or fix.

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 is a routine dependency cleanup in the BitBox02 hardware wallet firmware. The developers removed a direct dependency on a small library called 'bech32' and instead started using the version that is already included through the larger 'bitcoin' library. The actual code behavior is unchanged; this is purely about simplifying package management and avoiding version mismatches.

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 only reorders #include lines in a test helper file to match the project's code formatting rules. It makes no functional change and has no security relevance.

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.