BitBox02 firmware

This commit is a hardening improvement, not a fix for an active vulnerability. It reduces how often the BitBox02 hardware wallet talks to its secure chip (the Optiga) when checking a password. Previously, an extra secure-chip call was made to fetch and compare the seed; now the device compares a locally retained hash instead. This lowers the chance of hitting the secure chip's throttling/lockout counter during normal use, which could otherwise make the device temporarily unusable or even require reset. The change does not introduce a known exploit path.

This commit changes the order of operations in two developer-only GDB scripts used with J-Link debuggers. Previously the scripts loaded new firmware onto the device and then reset the CPU; now they reset the CPU first and then load the firmware. The change is described as a reliability fix for odd behavior seen when the device's watchdog timer is enabled. It only affects how engineers flash firmware during development/debugging and does not change any firmware code, cryptography, or user-facing behavior.

This commit adds two digital signature files for firmware version 9.23.2. These signatures are part of the project's reproducible-build attestation process, where an independent party (nickez) confirms that the published firmware matches the publicly available source code. No code, no bug fix, and no security vulnerability is present in the change itself.

This commit adds two digital signature files to the repository. They are a third-party reproducible-build assertion for the BitBox02 firmware version 9.23.2, signed by someone named 'sutterseba'. It does not change any firmware code, fix any bug, or introduce any new feature. There is no security issue here.

This commit simply adds official release signatures and build attestation files for firmware version 9.23.2. It does not change any source code, fix any bug, or alter any behavior of the BitBox02 device. There is nothing in the commit that introduces or addresses a security issue.

This commit is a routine code cleanup: it changes many Rust source files to import a small async helper module from a shared utility crate (`util::bb02_async`) instead of from the local crate (`crate::bb02_async`). There is no change to program logic, no bug fix, and no security-relevant behavior.

This commit adds the ability to include OP_RETURN outputs when signing Bitcoin transactions on a BitBox02 hardware wallet. OP_RETURN is a special Bitcoin output type used to embed small pieces of data (like text or hashes) on the blockchain. The device now shows the user the data being embedded and asks for confirmation before signing. The commit also enforces that OP_RETURN outputs must carry zero Bitcoin value, so no money can accidentally be burned into them.

This commit is a straightforward refactoring: it moves the BIP39 seed derivation and wallet-unlock logic from C into Rust, splitting one C function into a Rust wrapper plus two existing C helper functions. There is no change to the cryptographic behavior, no new user-facing feature, and no obvious security bug introduced. It appears to be a code-quality/architecture change to prepare for making the unlock flow asynchronous.

This commit is a simple internal code reorganization. It splits one existing function, keystore_unlock_bip39(), into three smaller functions: a check, a finalize step, and the original wrapper that calls both. The actual behavior and security checks appear unchanged. There is no indication this fixes or introduces a security issue.

This is a routine maintenance update that upgrades the Rust compiler toolchain from an older version to Rust 1.90.0 for the BitBox02 hardware wallet firmware. It refreshes many third-party Rust libraries (vendored dependencies), adjusts build configuration files, and saves a small amount of firmware space. There is no direct evidence in the commit of a security vulnerability being fixed or introduced. The main security consideration is that compiler and library updates can change generated code behavior, so thorough testing is warranted, but nothing in the diff points to an active security issue.

This commit is a performance and reliability improvement, not a security fix. It changes how the BitBox02 hardware wallet restores a wallet so that the device does not repeatedly ask its secure chip for the same seed during restore. Instead, the seed is passed directly to the BIP39 unlock step and verified against a stored hash. The goal is to avoid hitting the secure chip's throttling limit (133 events) when users repeatedly reset or restore the device. The change does not remove any security check; it only avoids an unnecessary secure-chip read by comparing a hash of the seed instead.

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 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.