Amber nodes are monitored by CommitWatch. Gray nodes are sampled from authenticated GitHub public commit search and may not represent complete contribution history.
This commit makes a single on-screen message scrollable. When swapping cryptocurrency, the destination amount can be very long and previously may have been cut off or unreadable. The change lets the user scroll through the full text before…
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 ex…
New user-facing signing path for EIP-1559 payment requestsPayment-request validation now covers both BTC and ETH/ERC-20 source assetsPlain ETH swaps require empty transaction data
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 adds a new optional 'payment request' field to Ethereum EIP-1559 signing requests in the BitBox02 firmware's protocol definitions and generated code. It does not contain any actual implementation of how that field is processed,…
New optional protobuf field added to a signing request messageNo validation or processing logic for the new field visible in the diffOnly test fixtures updated to include the new field as None
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 …
Refactor only: no new cryptographic operations, no change to trust boundaries, no change to signature verification algorithm.Amount comparison in `validate()` remains byte-for-byte against `payment_request.total_amount.to_le_bytes()`, preserving prior semantics for 64-bit little-endian values.UI text formatting is moved to the caller; this does not remove user confirmation, only changes where the formatted string is produced.
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…
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 validate…
New address-derivation validation path for BTC/LTC payment-request memosAddress mismatch check between derived address and memo-supplied addressInput validation: coin_type/unit consistency, simple-single-sig only, hardened account keypath element
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 …
New UI confirmation flow for cross-chain swapsInput validation added for swap amount string parsingRestriction of swap source accounts to BTC/LTC single-sig configurations
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 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 ro…
Addition of a new trusted signing identity to a payment-request allow-listCase-insensitive substring matching for one identity only, increasing name flexibilityNo validation, parsing, or cryptographic logic changes beyond identity lookup
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 …
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…
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 re…
New payment-request memo type with address ownership verification via keypath derivationTODO left in user_verify indicating UI confirmation for CoinPurchaseMemo is not yet implementedCross-module dependency introduced: Bitcoin payment-request validation now calls Ethereum address derivation
This commit fixes a typo-like bug in the BitBox02 hardware wallet's Ethereum transaction signing code. The firmware was supposed to reject a 'max_fee_per_gas' value that has an unnecessary leading zero byte, but it was accidentally checkin…
Incorrect field validated in EIP-1559 transaction parserLeading-zero canonicalization check bypassed for max_fee_per_gasPotential transaction-hash mismatch between host and device
This commit fixes a bug in the BitBox02 hardware wallet firmware where two Bluetooth privacy values were accidentally created from overlapping random bytes. The device intended to use the first 16 random bytes for a secret key (IRK) and a …
Information disclosure: 6 bytes of the 16-byte BLE Identity Resolving Key leaked into the public BLE identity address.Privacy weakening: partial IRK exposure reduces the effectiveness of BLE privacy/resolving mechanisms.Bug class: off-by/incorrect buffer offset in memcpy.
This commit is a straightforward internal refactoring: it moves the device-reboot-into-bootloader function behind a new 'System' hardware-abstraction trait so the rest of the Rust code calls it through a generic interface rather than direc…
Refactoring only: no change to reboot preconditions or user confirmation flowReboot capability remains behind existing authenticated HWW API and user confirmationNo new unsafe code introduced; one existing unsafe call is unchanged
This commit is a code cleanup that moves multisig account storage operations behind a hardware-abstraction layer so tests can use a fake memory instead of real device memory. It does not appear to fix or introduce a security vulnerability.…
Refactoring only: no change to production memory access semanticsHash type narrowed from Vec<u8> to [u8; 32], reducing risk of length confusionTest-only bug fixed: registration and subsequent API call now share the same TestingHal instance
This commit only fixes the formatting of license headers in automatically generated Python type-stub files. It moves the SPDX license notice from a standalone comment line into the generated docstring block. There is no change to program l…
This commit is a code cleanup and test-improvement change. It moves two device-attestation helper functions from a direct hardware call into a software 'hardware abstraction layer' (HAL) so the code can be tested without the real device. I…
Refactor only: no change to cryptographic operations, trust model, or data flowAttestation still uses SHA-256 of host challenge and secure-chip signingAdded unit tests increase coverage for attestation success and missing-certificate failure paths
This commit is a straightforward internal refactoring: it moves access to a device secret called the 'salt root' behind an existing hardware-abstraction layer so that automated tests can use a fake memory instead of real device memory. The…