BitBox02 firmware

This commit hardens how the BitBox02 firmware derives and exposes Cardano public keys (xpubs) by computing them twice and comparing the results. This matches a safety pattern already used for Bitcoin, meant to catch rare hardware errors or malicious bit flips that could silently produce a wrong xpub. A wrong xpub could lead a wallet app to generate addresses the user does not actually control, so the change is a defensive security improvement.

This commit only adds two sentences of documentation to the project's AGENTS.md file, giving reviewers guidance on what to check when a function call is removed in a code change. It does not modify any firmware code, cryptographic logic, build scripts, tests, or configuration. There is no security issue in this change.

This commit fixes a small but real bug in how the BitBox02 hardware wallet tells its Bluetooth chip what name to broadcast. The code that copies the device name into a fixed-size buffer correctly limited the copy to 63 bytes, but then accidentally reported the original, possibly longer length to the next processing step. That mismatch could make the Bluetooth formatting function read past the end of the 64-byte buffer, leaking nearby memory or crashing the device. The fix makes the reported length match the actual copied length.

This commit simply removes a software function named delay_is_elapsed that is no longer used anywhere in the code. It is a routine cleanup change with no apparent security relevance.

This commit fixes a bug in the BitBox02 hardware wallet's Rust delay system. Previously, calling delay_for() 10 times without cleanup caused the device to abort with 'Too many concurrent delays'. The fix ensures each delay is cancelled automatically when finished, preventing the device from crashing. It is a reliability fix rather than a clear security vulnerability, though any device crash could theoretically affect availability or user workflow.

This is a build-system cleanup, not a security fix. It moves test-only fake hardware code into a lower-level Rust crate and adds a linker trick so the fake disk storage implementation is not accidentally left out when building the desktop simulator. There is no change to how real devices work and no reported vulnerability.

This commit is a small code cleanup in a test-only file for the C simulator. It replaces calls to a C-style print function with Rust's standard println macro. There is no security relevance: no real secrets are handled, no production code is changed, and no vulnerability is introduced or fixed.

This commit is a routine internal code cleanup in the BitBox02 firmware. It moves a debug/error screen-printing function into a hardware-abstraction layer (HAL) so different parts of the code can use it without directly depending on low-level screen drivers. The visible behavior—showing error messages on the device screen—stays the same. There is no indication this fixes a security vulnerability or introduces a new attack path.

This commit simply renames an internal Rust module from `alloc` to `c_alloc` to avoid a naming conflict with Rust's standard `alloc` crate in a future change. The actual allocator code is identical; only file paths and a module reference are updated. There is no security-relevant change.

This commit is a small internal cleanup: it adds a new 'reset' method to the user-interface layer and makes the start of a new secure session call that method instead of calling a lower-level screen-clearing function directly. The behavior is essentially the same as before—clearing leftover screens when a new connection begins—so there is no new security problem. It is a refactoring change, not a fix for a known vulnerability.

This commit only changes how wallet addresses are shown on the BitBox02 screen. It inserts spaces every four characters (for example, a Bitcoin address becomes "bc1q k5f9 em9q ..." instead of one long string). There is no code that changes security logic, cryptography, or how transactions are approved. It is a user-experience improvement to make long addresses easier to read and compare.

This commit swaps out an old C ringbuffer for a new Rust-based byte queue used to hold data sent to the Bluetooth chip. The change touches many files but is mostly a rewrite/refactor. It removes several explicit 'will it fit?' size checks before adding data to the queue, and it changes how callers pass the queue around. The Rust ByteQueue implementation itself is not shown in the diff, so we cannot verify whether it safely handles overflow, memory allocation failures, or concurrent access. The change is therefore a security-relevant refactor with some risk, but no proven vulnerability is visible in the supplied commit.

This commit adds a brand-new Rust helper crate called bitbox-bytequeue. It is a small wrapper around Rust's standard growable queue type (VecDeque) that exposes a C-compatible API matching an older fixed-size C ringbuffer. The code is purely additive and does not change any existing security-critical logic. It includes overflow protection by deliberately crashing (panicking) if too many bytes are queued, which is intended to prevent memory exhaustion bugs.

This commit removes a duplicate function name from a Rust build script list. It is a harmless cleanup change with no security relevance.

This commit refactors how the BitBox02 hardware wallet resets its USB communication watchdog during long-running operations. It introduces a new method in the hardware abstraction layer so Rust code can reset the timeout without directly calling a lower-level USB module. The change itself is a structural cleanup; it does not appear to fix or introduce a security vulnerability, but it touches code that prevents tasks from being cancelled while handling sensitive operations like seed encryption and device reset.

This commit is a small internal code cleanup in the BitBox02 hardware wallet firmware. It moves the creation of an empty on-screen placeholder component into a common hardware-abstraction layer (HAL) so that both real device code and automated test code use the same interface. There is no direct security fix here; it is a refactoring that makes the code easier to test and maintain.

This commit only updates documentation comments and adds unit tests to clarify that a NULL pointer is acceptable when the length is zero. No code behavior was changed, so there is no security issue.

This commit adds a new 'coin purchase memo' feature to BitBox02 payment requests. It lets a payment request include details about a separate coin purchase (e.g., '0.25 ETH to address 0x...') and verifies that the listed Ethereum address really belongs to the wallet by deriving it from a provided keypath. The change is mostly a feature addition, but it introduces cross-currency validation logic and a TODO noting that the user-interface confirmation for this new memo type is not yet implemented.

This commit simply renames internal constants so they start with BITBOX02_. It does not change any values, memory addresses, or program behavior. The change is purely cosmetic/clarifying to avoid confusion when these constants are used in shared code.

This commit only adds unit tests for the Bluetooth firmware upgrade logic and improves the test-only mock memory implementation so it actually records firmware chunks. There are no changes to production code, no bug fixes, and no security-relevant behavior changes.

This commit is a routine code reorganization: it moves constants that describe where Bluetooth firmware is stored in SPI memory from C header files into Rust source files. The values themselves (32 KB max firmware size, two slots at addresses 0x00 and 0x8000, 4096-byte erase sectors) are unchanged. The change adds compile-time checks to ensure the Rust and C definitions stay consistent. There is no security bug being fixed here.

This commit is a software architecture refactor: it moves the Bluetooth firmware flashing logic behind a higher-level 'Memory HAL' interface. It does not change the actual security behavior of the firmware upgrade process; it only reorganizes the code so that the same operations go through a trait method instead of being called directly. There is no indication this fixes a vulnerability or introduces a new one.

This commit is a small internal code cleanup. It moves the way the device reads its Bluetooth firmware version from a direct hardware call into a shared memory interface, so the same code can be used in both real devices and automated tests. There is no visible change in behavior for end users, and nothing in the commit suggests a security fix or vulnerability.

This commit is a routine code reorganization. It moves the functions that read and write Bluetooth firmware metadata out of a low-level C-style module and into a Rust 'Memory' hardware-abstraction trait used by the rest of the firmware. The actual logic for reading, writing, and validating the metadata does not change. There is no indication this fixes a security bug; it appears to be part of making the code more testable and portable.

This commit is a small code cleanup in the BitBox02 hardware wallet firmware. It moves a direct call to a low-level screen-switching function into a proper hardware-abstraction trait, making the code more testable and consistent. There is no indication it fixes a security bug or changes user-visible behavior.