BitBox02 firmware

This commit only adds missing test setup calls to two automated unit tests in the Ethereum signing code. It does not change any production firmware behavior, user-facing functionality, or security logic. There is no indication this fixes a vulnerability or affects real devices.

This commit fixes a serialization bug in the BitBox02 firmware's payment request validation for Ethereum transactions. Previously, Ethereum payment amounts were encoded as big-endian (most-significant-byte-first), but the SLIP-24 standard requires them to be little-endian (least-significant-byte-first). Because the device signs the payment request using one byte order but the validation code used another, a payment request could be generated that the device would accept even if the actual transaction amount did not match what the user saw on screen. The fix changes the code to serialize Ethereum amounts as 32-byte little-endian values, matching the standard and preventing amount mismatches.

This commit only adds a single line to the product changelog describing a new feature: support for swaps in payment requests. There are no code changes, no bug fixes, and no security-related content in the diff.

This commit adds a new on-screen user-interface component for confirming cryptocurrency swaps. It is a feature addition that refactors how swap confirmations are displayed, replacing a generic confirmation screen with a dedicated swap screen. There is no direct evidence in the commit that this fixes a security vulnerability or introduces a new attack path.

This commit is a code reorganization: it moves the Rust bindings and wrappers for the BitBox02's secure chip (ATECC/Optiga) out of the general bitbox02-sys crate into two new dedicated crates, bitbox-securechip-sys and bitbox-securechip. It does not change the underlying C secure-chip implementation or add new user-facing behavior. The change is architectural cleanup, not a security fix or vulnerability.

This commit fixes a tiny user-interface bug on the BitBox02 hardware wallet. When a Bitcoin or Ethereum payment request was invalid, the device was accidentally showing a success icon (checkmark) instead of an error icon. The change flips one boolean argument so the screen now correctly shows an error icon. It does not change whether the transaction is rejected—the device still refuses to sign.

This commit only updates the CHANGELOG.md file to mark the release of firmware version 9.26.0. It does not change any source code, configuration, or executable files. There is no security-relevant change in the diff itself.

This is a one-line change updating a public key value inside a unit test. It is not a security fix and does not change any production code. The commit message says it fixes a unit test regression from an earlier commit.

This commit simply swaps out one public key for another in a list of trusted payment-request identities used by the BitBox02 hardware wallet's swap feature. There is no code change beyond replacing the hard-coded key. On its own, the diff does not show a vulnerability being fixed; it is best understood as a routine key rotation or partner update.

This commit removes an on-screen confirmation that told users which account would receive funds during a cryptocurrency swap. The remaining screen still shows the amount and destination coin type, but no longer shows the specific account number. The underlying cryptographic keypath validation is still performed, so the technical security check remains. The change is presented by the developer as a user-experience improvement, not as a security fix.

This commit only cleans up internal unit tests for Ethereum typed-message signing. It removes an unnecessary Rust borrow-checking wrapper (RefCell) from test code, with no change to the actual firmware behavior that users interact with. There is no security fix or vulnerability here.

This commit is a routine internal refactoring of how the BitBox02/BitBox03 firmware handles delays. It moves delay logic behind a new shared 'Timer' interface and removes old device-specific delay modules. There is no indication in the commit that this fixes a security bug or introduces a vulnerability; it appears to be a code-cleanup and architecture change.

This commit replaces a Rust 'todo!()' placeholder with a stub that displays a 'TODO' status message during an unlock animation. It is a routine development stub, not a security fix or vulnerability. There is no evidence of malicious behavior or security relevance.

This commit is a routine feature implementation for the BitBox03 hardware wallet. It adds a new status screen (success/error) and an internal delay/timer helper used to show that screen for two seconds. There is no security fix or vulnerability present in the diff.

This commit replaces a placeholder 'not yet implemented' stub with a working on-screen keyboard for entering text and passwords on the BitBox02/03 hardware wallet. It is a normal feature implementation, not a security fix or vulnerability.

This commit replaces an unimplemented placeholder ('todo!()') for a screen reset function with actual code that clears the user-interface stack. It is a normal completion of missing functionality. There is no direct evidence in the commit that this fixes an exploitable security bug, but leaving a reset operation unimplemented could previously have left stale UI state in place during sensitive workflows.

This commit simply teaches the BitBox Python library to recognize a new hardware device model, the BitBox03. It adds the model name to an internal list and tells the library how to interpret the device-info bytes sent by a BitBox03. There is no security fix or vulnerability here—just routine support for a new product variant.

This commit adds a new Rust-based USB transport layer for BitBox hardware wallets. It reassembles U2F HID messages and routes vendor commands to the existing async USB task system. The change also hardens the async executor by handing out owned responses instead of copying into caller buffers, and by resetting stale state when a task is cancelled or times out. There is no vendor statement that this fixes a security bug; it reads as a feature/refactoring commit with defensive hardening.

This commit adds support for EIP-1559 Ethereum transactions in the BitBox02's payment-request (swap) feature. It lets users verify and sign Ethereum and ERC-20 token swaps that include a merchant payment request, similar to what already existed for Bitcoin. The change is a feature addition, not a fix for a known vulnerability.

This commit is a simple code cleanup: it moves two existing blocks of Ethereum fee-verification logic into new helper functions without changing what the code actually does. There is no visible security fix or behavior change.

This commit is a code cleanup that makes the payment-request code less Bitcoin-specific so it can be reused for other coins in the future. It does not add new user-facing features or fix a known bug. The changes move amount formatting and coin-type handling from the shared payment-request module into the Bitcoin signing code, and adjust internal test helpers. There is no indication in the commit that this fixes a security vulnerability.

This commit is a code reorganization: it moves SmartEEPROM handling (a flash-backed memory feature) out of the general Memory and System modules into a new dedicated Eeprom trait in the hardware abstraction layer. The same underlying functions are still called, and the unlock-attempt counter behavior is preserved. There is no obvious security bug introduced, but the change touches code that protects device reset and unlock-attempt limits, so it deserves careful review to confirm no behavior was accidentally dropped.

This commit is a pure code refactor: it moves the payment_request module from the bitcoin-specific directory up to the general API directory. The actual logic, security checks, and behavior of the payment request code are unchanged. No new vulnerabilities are introduced by this move.

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