BitBox02 firmware

This is a build-system refactoring commit. It moves the generation of version.h and rust.h out of CMake and into a Python script and Rust build.rs, so the Rust code can be built standalone without CMake. There is no change to runtime firmware behavior, no bug fix, and no security patch visible in the diff.

This commit adds a new graphical simulator for the BitBox02 hardware wallet using the LVGL UI library. It is a large development-only change that introduces simulator code, vendored Rust dependencies, and build tooling. There is no indication from the commit title, message, or diff that this fixes or introduces any security vulnerability.

This is a small code cleanup change. It removes a local helper function that wrapped rust-bitcoin's variable-length integer serializer, and instead calls rust-bitcoin's serializer directly at each place it is used. The actual bytes produced are identical, so this does not change behavior or fix a security issue.

This commit replaces a hand-written Bitcoin variable-length integer encoder with one from the well-known rust-bitcoin library. The old code appears to have been correct, so this is a code-quality and maintainability improvement rather than a fix for a known security bug. It reduces the chance of future mistakes by relying on a widely reviewed standard implementation.

This commit only changes how much output is shown when running Rust unit tests during firmware builds. It makes the tests less chatty unless verbose mode is explicitly requested. There is no security relevance.

This is a trivial developer tooling change. It moves command-line options for the Python code formatter (black) from one script into another so that the formatting script works correctly. There is no change to firmware, cryptography, wallet behavior, or anything user-facing.

This commit adds support for deriving and verifying Bitcoin-family destination addresses inside payment-request memos used for coin swaps. It extends the existing Ethereum-only address-derivation feature to also cover BTC/LTC, and validates that the claimed swap destination address actually matches the derived one. There is no direct evidence this fixes an active security bug; it appears to be a feature addition that also hardens validation.

This commit is a routine code cleanup: it removes several C functions that control the Bluetooth chip and replaces their use with equivalent Rust functions. There is no indication in the commit itself that this fixes a security bug or introduces a vulnerability. It is a refactoring change.

This commit exposes a Rust Bluetooth Low Energy (BLE) chip control library to C code. It adds C-callable functions for powering down, resetting, setting product/name strings, and checking connection state. The change is primarily an interface/API export with no obvious security bug, but it introduces new unsafe C boundaries that must be used correctly by callers.

This commit is a routine code reorganization: it moves the Rust code that controls the Bluetooth Low Energy (DA14531) chip from one internal module into its own separate crate. The actual logic, commands, and behavior are copied almost unchanged; only the file paths and import names change. There is no indication this fixes or introduces a security problem.

This commit adds two new helper functions in Rust for talking to the Bluetooth chip inside the BitBox02 hardware wallet: one to reset the chip and one to ask for its current connection state. It also adds unit tests that check the exact bytes sent. There is no security issue visible in this change; it is a straightforward feature addition with tests.

This commit rewrites low-level Bluetooth setup commands for the BitBox02 hardware wallet from C bindings into safer Rust code. It is a routine refactoring/porting change with no obvious security bug, though it removes an old C-string conversion and adds a length check for the product string.

This commit adds a new on-device user interface flow for cryptocurrency swaps, where a user can exchange Bitcoin or Litecoin for an Ethereum-like coin through a payment request. The code adds validation rules and user confirmation screens so the hardware wallet can show what is being swapped and where the received coins will go. The change is a feature addition with defensive checks, not a clear fix for an existing vulnerability.

This commit adds a small convenience script that lets developers choose whether project commands run directly on their computer or inside the project's Docker container. It only changes developer tooling and documentation; it does not touch the firmware, wallet logic, cryptography, or any user-facing security feature.

This commit is a routine build/maintenance change. It updates two helper scripts to explicitly call Python 3 instead of relying on a system default 'python' command, and removes a Dockerfile step that forced 'python' to point to Python 3. There is no security-relevant change to the firmware or its behavior.

This is a routine code cleanup commit that reorganizes how two internal Rust software components connect to each other. It removes a circular dependency where a higher-level crate called 'bitbox02-rust' depended on a lower-level crate called 'bitbox02', and vice versa. The change moves a small piece of noise-cryptography-related code into the lower-level crate and adjusts build configuration files accordingly. There is no indication this fixes a security vulnerability or changes user-visible behavior.

This is a minor Python import cleanup in a developer/test script. It changes how one internal class is imported so that the script works reliably when installed in 'editable' mode. There is no security issue here.

This commit is a routine internal refactoring: it moves the lookup of which secure chip type (ATECC or Optiga) is present from an older C memory module to a newer Rust memory module. The actual chip-detection logic and behavior do not change; only which internal API is called. There is no indication this fixes or introduces a security vulnerability.

This commit is a software architecture cleanup: it moves some type definitions and helper functions so that secure-chip code (ATECC/Optiga) no longer depends directly on the BitBox02-specific memory module. The goal stated by the developer is to make those modules reusable in a future BitBox03. There is no direct evidence in the commit that it fixes a security vulnerability, changes cryptographic behavior, or introduces a bug.

This commit removes a small C wrapper file (salt.c/salt.h) and replaces its use with direct calls to an equivalent Rust function. The actual password-stretching and hashing logic is unchanged; it is only moved from one place in the code to another. There is no indication this fixes or introduces a security vulnerability.

This commit adds a new trusted Bitcoin payment-request signer called SWAPKIT to the BitBox02 hardware wallet. It also makes matching more flexible for SWAPKIT so names like 'swapkit (Provider)' or 'SwapKit' are accepted. The change is a routine allow-list update, not a fix for a security bug.

This commit fixes a bug in the BitBox02 hardware wallet's handling of a tamper-resistant counter chip (Optiga). Previously, if the counter reset failed, the device silently ignored the error and continued to write metadata. Now the error is checked and the setup is aborted. This restores safer behavior and prevents the device from continuing in a potentially inconsistent state.

This commit hardens the project's automated CI workflow in two ways: it pins a third-party Mattermost notification action to a specific, unchangeable version (instead of a moving 'master' branch), and it restricts the job's GitHub token permissions to read-only access to repository contents. These are defensive security improvements that reduce supply-chain and privilege risks, but the commit itself does not fix an active vulnerability.

This commit fixes a bug in the BitBox02 hardware wallet's Ethereum transaction signing. When signing an Ethereum transaction whose 'data' field is exactly 1 byte long and is streamed from the host computer in chunks, the device could call for the first byte before it had actually been fetched, leading to a crash or failed signing. The fix makes the first-byte lookup asynchronous so it can request the byte from the host on demand, and avoids asking for an extra chunk when the whole payload is just that one byte. New unit tests and regenerated test vectors confirm the 1-byte case now works.

This commit only updates an internal coding-style guide (AGENTS.md) for developers. It adds a recommendation to use a particular Rust macro (`hex!`) when writing unit tests. There is no code change, no bug fix, and no security relevance.