BB
← All projectsBitBox

BitBox02 firmware

Firmware and bootloader for BitBox02 signing devices.

BitcoinHardware walletsNormal
Repository coverage

647 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

193security candidates127second-pass queue230AI analyses
28commits · 30 days
47commits · 60 days
312commits · 180 days
647commits · 365 days
Backfill bands
Aug 5 → Feb 6335 seen28 candidatesComplete
Feb 6 → Jun 6265 seen19 candidatesComplete
Jun 6 → Jul 619 seen5 candidatesComplete
Jul 6 → Aug 526 seen3 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

59/100 average clarity
65Strong · 80–100
281Adequate · 60–79
230Thin · 40–59
71Opaque · 0–39
23security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Marko Bencun390117135258
benma's agent892834162
Niklas Dusenlund1112931059
cedwies1257063
Tomas Vrba947074
Cedric Wiese1239049
Jad811062
thisconnect211072
benma211074
Niklas111035
Yasser Aziza111070
Patrick Steiger111045
Analysis record

Published AI watches

Last scanned 52 minutes ago

Moderate 60 AI analysisMessage 90 · Strong
BB BitBoxBitBox02 firmware BitcoinHardware wallets

backup: validate decoded seed length

This update fixes a bug in how the BitBox02 hardware wallet reads backup files from an SD card. A tampered backup file could claim to contain a seed longer than the 32-byte limit, which previously caused the device to panic (crash) when li…

Out-of-bounds/panic condition in backup parsingMissing input validation on decoded protobuf fieldSD-card backup file could be attacker-controlled
80baf1eeby benma's agent+34−01 file
Vendor flagged security relevance
Low 39 AI analysisMessage 73 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

rust: initialize C output buffers

This commit fixes a class of low-level memory-safety bugs where Rust code was given buffers containing uninitialized bytes. Rust's rules require every byte of a slice to be initialized, even if the function will overwrite them. Passing uni…

Undefined behavior at C/Rust FFI due to uninitialized buffers being treated as Rust slicesPotential optimizer-dependent behavior from violating Rust slice initialization rulesHardening of cryptographic output paths (SHA-256, HMAC-SHA256, HMAC-SHA512)
511018eaby benma's agent+52−2713 files
Vendor flagged security relevance
High 74 AI analysisMessage 78 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

eth: limit EIP-712 recursion depth

This commit adds a hard limit on how deeply nested Ethereum typed-message (EIP-712) structures can be when the BitBox02 hardware wallet signs them. Without the limit, an attacker could craft a message type that refers to itself over and ov…

Adds explicit recursion-depth cap to attacker-controlled input parsingPre-validates schema roots before host callbacks or user confirmationProtects against stack exhaustion / denial-of-service from deeply nested EIP-712 types
4ccadcc0by benma's agent+196−451 file
No security note in commit
Informational 15 AI analysisMessage 50 · Thin
BB BitBoxBitBox02 firmware BitcoinHardware wallets

py: extract bootloader connection

This commit is a minor code cleanup in a Python helper script. It moves existing bootloader connection logic into a small nested helper function to satisfy a style checker (pylint's limit on the number of return statements). No behavior ch…

886113d0by benma's agent+10−61 file
No security note in commit
Low 42 AI analysisMessage 78 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Warn before truncated value displays

This commit adds a warning screen to the BitBox02 hardware wallet whenever a long message or value is about to be shown in a truncated form. Previously, the device could silently cut off the end of very long transaction details, message da…

UI truncation warning added before oversized confirmation bodiesCentralized body-size limit to keep Rust and C UI limits in syncReplaced duplicated warning logic with shared confirm_value helper
5b3aee6fby benma's agent+266−4710 files
No security note in commit
Informational 12 AI analysisMessage 45 · Thin
BB BitBoxBitBox02 firmware BitcoinHardware wallets

releases: add v9.26.2, v9.26.3 and v9.26.4

This commit is a routine release-management update. It adds signed build assertions for three new BitBox02 firmware versions (9.26.2, 9.26.3, 9.26.4) and updates the release documentation and build helper script. The build script now delet…

No firmware source code is modifiedNo cryptographic primitives or protocols are changedNo bug fixes or vulnerability mitigations are present in the diff
eed2e68eby Marko Bencun+79−116 files
No security note in commit
Informational 21 AI analysisMessage 68 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

eth: loosen EIP-712 identifier validation

This firmware update relaxes the rules for valid Ethereum typed-data (EIP-712) names so they can contain a colon (:), which some decentralized apps use as a namespace separator. Member names still cannot contain colons. The change is prese…

Input validation relaxation for externally supplied EIP-712 type namesExplicit claim that ':' cannot forge encodeType boundariesMember-name validation remains strict
9703d8d9by Marko Bencun+50−43 files
No security note in commit
Moderate 59 AI analysisMessage 69 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Limit SD erase file size

This commit fixes a bug in how the BitBox02 hardware wallet wipes files from its SD card. Before erasing a file, the device now checks the file's reported size against a safe maximum. Without this check, a tampered SD card could claim a fi…

CVE-2026-6682 referenced in commit messageMalformed FAT directory entry could cause excessive overwrite loopDenial-of-service via SD card tampering
2453f528by Marko Bencun+4−01 file
Vendor flagged security relevance
High 70 AI analysisMessage 66 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Validate mounted FAT geometry

This update adds a safety check when the BitBox02 hardware wallet mounts a microSD card. A malicious or deliberately malformed FAT filesystem could trick the device's file-system library into placing user data inside attacker-controlled bo…

Fixes integer-wrap / geometry confusion in FAT mount logicAdds explicit post-mount validation of filesystem metadataPrevents data area from landing inside attacker-controlled FAT sectors
01c017d6by Marko Bencun+21−01 file
Vendor flagged security relevance
Low 27 AI analysisMessage 69 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Update FatFs to R0.16

This commit updates the third-party FatFs file-system library inside the BitBox02 firmware from version R0.14b to R0.16 plus an upstream patch. The change is a routine dependency refresh: it replaces the vendored source files with the newe…

Third-party dependency update (FatFs R0.14b -> R0.16+p1)No explicit security claim in commit messageNo CVE or advisory referenced in commit or supplied references
9f2b493dby Marko Bencun+3842−256979 files
No security note in commit
Low 34 AI analysisMessage 59 · Thin
BB BitBoxBitBox02 firmware BitcoinHardware wallets

api: add BitBoxSync

This commit adds a brand-new firmware feature called BitBoxSync, which lets the BitBox02 hardware wallet participate in a sync service by proving its identity, signing login/admin intents, and decrypting namespace encryption keys. The code…

New cryptographic API surface added to the hardware wallet (Ed25519, X25519, HKDF, AEAD)Vendored third-party crate `hkdf` introduced into the firmware supply chainNew user-confirmation flow for signing sync intents; one operation (UnwrapNamespaceDek) deliberately skips confirmation
54cdb54dby Marko Bencun+2883−2230 files
No security note in commit
Informational 0 AI analysisMessage 45 · Thin
BB BitBoxBitBox02 firmware BitcoinHardware wallets

blupgrade: update stage1 binaries to v1.2.2

This commit simply swaps in newer pre-built bootloader stage1 binary files (version 1.2.2 replacing 1.2.1) for four BitBox02 hardware variants and updates the corresponding checksum list. The actual code inside the new binary files is not …

5940a800by Marko Bencun+8−86 files
No security note in commit
Moderate 59 AI analysisMessage 50 · Thin
BB BitBoxBitBox02 firmware BitcoinHardware wallets

bootloader/stage1: fix erase handling for partially erased blocks

This update fixes the BitBox02 bootloader's firmware-erase routine. Previously, when erasing leftover padding after a firmware update, the bootloader started erasing at the exact page where the firmware ended. Because flash memory can only…

Bootloader firmware erase routine could erase a flash block containing both firmware and paddingFix aligns erase start to erase-block boundary and re-checks erased state before erasingChangelog describes the change as a fix for 'partially erased flash blocks'
b31206a8by Marko Bencun+23−83 files
No security note in commit
Informational 15 AI analysisMessage 45 · Thin
BB BitBoxBitBox02 firmware BitcoinHardware wallets

blupgrade: add stage0/stage1 production binaries

This commit adds production bootloader upgrade files for the BitBox02 hardware wallet and updates build scripts to use them. It is a routine asset-management change: replacing placeholder development hashes with real signed production bina…

8db4b0dcby Marko Bencun+26−1720 files
No security note in commit
Informational 20 AI analysisMessage 83 · Strong
BB BitBoxBitBox02 firmware BitcoinHardware wallets

blupgrade: keep dev stage1 unsigned

This commit fixes a build script used only for development/testing versions of the BitBox02 bootloader upgrade. It makes the development-stage1 bootloader images unsigned again, while keeping production images fully signature-verified. The…

Signature verification relaxed only for development buildsProduction payload validation still requires signaturesDevelopment stage0 already skipped stage1 signature verification per commit message
476b90e3by Marko Bencun+9−69 files
No security note in commit
High 76 AI analysisMessage 23 · Opaque
BB BitBoxBitBox02 firmware BitcoinHardware wallets

security improvements

This BitBox02 firmware update is a broad security patch that fixes several independent bugs: it prevents a maliciously oversized USB report from overflowing memory, stops a corrupted Bluetooth pairing database from being read or written wi…

Bounds check added to USB HID Set Report input lengthBLE bond DB length validation hardened against negative and oversized valuesBootloader firmware image size limit relaxed to intended maximum
cbb40634by Marko Bencun+1117−25021 files
Vendor flagged security relevance
Low 46 AI analysisMessage 60 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

bootloader: allow full sized images

This commit fixes a bootloader bug where the device rejected firmware updates that used the maximum allowed size. The off-by-one check meant legitimate full-sized firmware images could not be installed, potentially blocking updates. The fi…

Off-by-one input validation in firmware-update pathBootloader change affecting firmware chunk count acceptanceCHANGELOG labels the change as a bugfix for full-sized firmware upgrades
f60b93ccby Marko Bencun+5−33 files
No security note in commit
Moderate 59 AI analysisMessage 28 · Opaque
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Add bootloader update

This is a large firmware commit that adds a new two-stage bootloader update mechanism for the BitBox02 hardware wallet. It replaces the old single bootloader with a small, fixed 'stage0' plus a separately signed 'stage1', and ships a speci…

Bootloader architecture changed from monolithic to two-stage (stage0 + signed stage1).Firmware signature hash now includes a 16-bit product_id, binding firmware to product variant.Root public keys were rotated/replaced with a single set across all products.
3f1f3172by Marko Bencun+5003−52379 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 73 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Add flash data backup scripts

This commit adds two helper scripts for developers to back up and restore BitBox02 flash memory areas using a Segger J-Link debugger. The scripts require physical hardware access and a debugging probe, and they are not part of the firmware…

285fa768by Niklas Dusenlund+383−03 files
No security note in commit
Informational 15 AI analysisMessage 40 · Thin
BB BitBoxBitBox02 firmware BitcoinHardware wallets

bb03 UI: placeholder BTC signing workflows

This commit replaces unfinished placeholder code (which would crash with 'todo!()') with simple working user-interface placeholders for Bitcoin signing demonstrations. It adds basic on-screen prompts to confirm a recipient/amount and a tot…

f7b0b082by Jad+24−121 file
No security note in commit
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Security candidatekeystore: reduce secure chip operations by precomputing fingerprintby Marko Bencun · e3b21df8 · Sep 8, 2025 · 8 filesMessage 73 · AdequateInformational 19Details
Commit message · Marko Bencun

keystore: reduce secure chip operations by precomputing fingerprint

The root fingerprint API call, calling
`bitbox02_rust::keystore::root_fingerprint()`, used two securechip
operations. Using too many operations too quickly in Optiga leads to
throttling, and the BitBoxApp fetches the root fingerprint every time
the BitBox is unlocked.

We can get away with not using hte securechip at all to get the root
fingerprint, by computing and storing it during unlock.

The global static mut could have lived in keystore.c with the other
static muts there, but adding more C code and Rust wrappers seemed
wrong. For now it lives in bitbox02::keystore, and would move over to
bitbox02_rust::keystore when the unlocking functions are migrated to Rust.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Informational 19/100

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.

Security candidatetest: refactor tests/simulator to compile more with cargoby Niklas Dusenlund · cf482332 · Sep 8, 2025 · 78 filesMessage 95 · StrongInformational 15Details
Commit message · Niklas Dusenlund

test: refactor tests/simulator to compile more with cargo

* Build C files from build.rs script and remove "bitbox_merged" hack.
* Move cmake specifics out of build.rs.
* Rust functions exposed as a C api has been moved to the respective
crates to remove circular dependencies.

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

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.

Security candidaterust: Reduce count of depsby Niklas Dusenlund · 19d84ffe · Sep 5, 2025 · 414 filesMessage 72 · AdequateInformational 15Details
Commit message · Niklas Dusenlund

rust: Reduce count of deps

We use the same versions of the deps as the standard library to avoid
vendoring additional versions

72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Explains rationale or failure mode
Why it was queued
authentication path
AI analysis · Informational 15/100

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.

Security candidateexternal/vendor: update bitcoin to v0.32.7by Marko Bencun · 3d18dfdf · Sep 3, 2025 · 46 filesMessage 45 · ThinLow 45Details
Commit message · Marko Bencun

external/vendor: update bitcoin to v0.32.7

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Low 45/100

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.

Security candidatekeystore: port keystore_secp256k1_schnorr_sign to Rustby Marko Bencun · a6b69b33 · Sep 3, 2025 · 7 filesMessage 50 · ThinInformational 11Details
Commit message · Marko Bencun

keystore: port keystore_secp256k1_schnorr_sign to Rust

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
seed or entropy pathsigning or wallet path
AI analysis · Informational 11/100

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.

Security candidaterust: bump to 2024by Niklas Dusenlund · 1a3bc6ee · Sep 2, 2025 · 74 filesMessage 43 · ThinInformational 15Details
Commit message · Niklas Dusenlund

rust: bump to 2024

We already had 2024 in one of the newer crates. This made rustfmt
confused, as rustfmt.toml had 2021.

43/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides an explanatory body
Why it was queued
cryptography-sensitive pathseed or entropy pathsigning or wallet path
AI analysis · Informational 15/100

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.

Security candidaterust: update bip32-ed25519by Marko Bencun · 17c3d0a4 · Sep 2, 2025 · 9 filesMessage 35 · OpaqueInformational 21Details
Commit message · Marko Bencun

rust: update bip32-ed25519

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 21/100

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.

Security candidateexternal: add and use secp256k1-zkp directly, remove libwally-coreby Marko Bencun · aa3703cd · Sep 2, 2025 · 7 filesMessage 85 · StrongInformational 13Details
Commit message · Marko Bencun

external: add and use secp256k1-zkp directly, remove libwally-core

We currently use secp256k1-zkp as bundled by libwally-core. As we
remove libwally-core as dependency, and need to directly include
secp256k1-zkp.

We use a new branch of our fork rebased on current upstream master,
because they added CMake support.

This removes another ~6.4kB from the resulting multi binary.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
cryptography-sensitive path
AI analysis · Informational 13/100

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.

Security candidateunit-test: don't use libwally bip32by Marko Bencun · 5929b40f · Sep 2, 2025 · 1 fileMessage 55 · ThinInformational 12Details
Commit message · Marko Bencun

unit-test: don't use libwally bip32

Trying to remove the libwally C dep.

55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
secret or key material
AI analysis · Informational 12/100

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.

Security candidaterust: pass Rust secp256k1 context instead of using wally's contextby Marko Bencun · bec904a4 · Sep 2, 2025 · 4 filesMessage 65 · AdequateInformational 16Details
Commit message · Marko Bencun

rust: pass Rust secp256k1 context instead of using wally's context

Step-by-step removal of `wally_get_secp_context()`.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 16/100

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.

Security candidaterust: introduce global secp256k1 contextby Marko Bencun · 6c96b561 · Sep 2, 2025 · 5 filesMessage 76 · AdequateInformational 12Details
Commit message · Marko Bencun

rust: introduce global secp256k1 context

Creating/destroying instances of the context is expensive. The
secp256k1 library provides
GlobalContext (https://docs.rs/secp256k1/0.31.1/secp256k1/global/struct.GlobalContext.html),
but only on std. We add a port of this to no_std.

76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 12/100

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.

Security candidatetests: rename mocks to fakesby Niklas Dusenlund · 442462c3 · Sep 1, 2025 · 43 filesMessage 55 · ThinInformational 15Details
Commit message · Niklas Dusenlund

tests: rename mocks to fakes

55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
seed or entropy pathsigning or wallet path
AI analysis · Informational 15/100

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.

Security candidatetest: Moved mocking specific things to unit testsby Niklas Dusenlund · 08b47ca1 · Sep 1, 2025 · 20 filesMessage 90 · StrongInformational 15Details
Commit message · Niklas Dusenlund

test: Moved mocking specific things to unit tests

We want to share as much of the simulation code as possible without the
simulator depending on the mocking framework. This commit refactors
cmocka specific code to the unit-test dir.

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
seed or entropy pathparser or protocol path
AI analysis · Informational 15/100

This commit is a pure internal test-code refactor. It moves CMocka-specific mock functions out of a shared hardware-mocks library and into the unit-test directory so that the simulator no longer depends on the CMocka testing framework. No production firmware code is changed, and nothing in the commit affects the security of the shipped BitBox02 device.

Security candidateMove vendored rust depsby Niklas Dusenlund · 2dfc3729 · Aug 27, 2025 · 4769 filesMessage 28 · OpaqueInformational 15Details
Commit message · Niklas Dusenlund

Move vendored rust deps

`src` should only contain our sources

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
cryptography-sensitive pathseed or entropy pathsigning or wallet pathboot or update pathauthentication pathparser or protocol path
AI analysis · Informational 15/100

This commit is a large but purely organizational change: it moves all vendored (third-party) Rust dependencies from the `src` directory to a new `external/vendor` directory. Only two small configuration files were actually modified: `.cargo/config.toml` (to point Cargo at the new vendor directory) and `external/vendor-rust.sh` (a helper script). The millions of added and removed lines are just the same dependency files being relocated, not new code. There is no visible change to the firmware's behavior or security logic.

Security candidaterust: clean up wally_sha512 remnantsby Marko Bencun · fbb6e6c7 · Aug 27, 2025 · 7 filesMessage 68 · AdequateInformational 18Details
Commit message · Marko Bencun

rust: clean up wally_sha512 remnants

Since bitbox02::sha512 now uses bitcoin::hashes and is not wrapping
the wally C function, we can remove that function and inline it.

bitbox-aes does not need the feature switch anymore as a result.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Informational 18/100

This commit is a routine code cleanup in the BitBox02 hardware wallet firmware. It removes an old wrapper around a C-language SHA-512 function and switches the Rust code to use a pure-Rust SHA-512 implementation from the `bitcoin::hashes` library. It also removes an unused feature flag and simplifies dependencies. There is no direct evidence in the commit that this fixes a security vulnerability.

Security candidateuse Rust hmac/sha256/sha512 over libwally's functionsby Marko Bencun · 7643ec20 · Aug 27, 2025 · 16 filesMessage 65 · AdequateLow 32Details
Commit message · Marko Bencun

use Rust hmac/sha256/sha512 over libwally's functions

Aiming to remove the libwally dependency.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Low 32/100

This commit swaps the cryptographic hashing and HMAC functions used throughout the BitBox02 firmware from the libwally library to equivalent Rust implementations. The goal is to remove the libwally dependency. The change touches sensitive code paths such as seed stretching, U2F key generation, and secure-chip authorization, but the commit itself does not claim to fix any security bug. The main risk is that any subtle difference in behavior between the old and new implementations could affect how keys are derived or how the device authenticates, though the diff shows no obvious vulnerability.

Security candidaterust: since rust 1.64, bindgen can use the c types from coreby Niklas Dusenlund · 9e5ebf7e · Aug 27, 2025 · 14 filesMessage 65 · AdequateLow 29Details
Commit message · Niklas Dusenlund

rust: since rust 1.64, bindgen can use the c types from core

There was a bug also, (u)int is 32bits on 64 byte systems.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
cryptography-sensitive pathseed or entropy path
AI analysis · Low 29/100

This commit updates the BitBox02 firmware's Rust code to use Rust's built-in C type definitions instead of a custom module. The commit message notes a bug: the custom module incorrectly defined 'unsigned int' as 64 bits on 64-bit systems, when it should always be 32 bits. The change removes the buggy custom type definitions and switches to the standard Rust core::ffi types. This is primarily a code-quality and correctness fix, but the wrong type sizes could have caused subtle memory or interface mismatches between Rust and C code, especially during testing on 64-bit computers.

Security candidatebitbox02-rust-c: fix wrong features in platform-bitbox02plusby Marko Bencun · 59a4c0ff · Aug 27, 2025 · 1 fileMessage 65 · AdequateInformational 19Details
Commit message · Marko Bencun

bitbox02-rust-c: fix wrong features in platform-bitbox02plus

This platform is only activated in Nova bootloaders, where we don't
need these deps.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
update trust
AI analysis · Informational 19/100

This is a tiny build-configuration fix for a specific BitBox02 hardware variant (the 'BitBox02 Plus' platform used in Nova bootloaders). The change removes two optional Rust dependencies that were accidentally enabled for that platform. The commit message says those dependencies are not needed there. There is no direct evidence in the commit of a security vulnerability; it looks like a cleanup to avoid compiling unnecessary code in the bootloader.

Security candidatemove bip39 functionby Marko Bencun · 14417b14 · Aug 27, 2025 · 5 filesMessage 43 · ThinInformational 15Details
Commit message · Marko Bencun

move bip39 function

The bitbox02 crate is meant to wrap C code, which this function is not
doing anymore.

43/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides an explanatory body
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 15/100

This commit simply moves a helper function that looks up a BIP39 word by its index from one Rust module to another. The code itself is unchanged, and there is no indication of a security fix or vulnerability.

Security candidateport bip39 functionality from libwally-core to rust-bip39by Marko Bencun · 04833009 · Aug 27, 2025 · 11 filesMessage 85 · StrongLow 27Details
Commit message · Marko Bencun

port bip39 functionality from libwally-core to rust-bip39

rust-bip39 is much faster than libwally, so the unlock animation is
speed up so that the last animation frame lingers for a bit, otherwise
the change felt too abrupt.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Low 27/100

This commit replaces the BIP39 (seed phrase) implementation inside the BitBox02 hardware wallet from one library (libwally-core) to another (rust-bip39). The main user-visible reason is speed: unlocking the device is now faster, so the unlock animation was shortened. The change touches how seed phrases are converted to cryptographic seeds and how individual BIP39 words are looked up. There is no direct evidence in the commit that this fixes a known security bug, but any change to cryptographic code can introduce subtle risks, so it deserves careful review.

Security candidateu2f: port app_string to Rust using rust-bip39 for the short mnemonicby Marko Bencun · 1a5d05cb · Aug 26, 2025 · 6 filesMessage 73 · AdequateInformational 19Details
Commit message · Marko Bencun

u2f: port app_string to Rust using rust-bip39 for the short mnemonic

Introducing rust-bip39 to get rid of libwally's bip39, starting with
u2f, where libwally was used to create the short mnemonic for unknown
sites.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key material
AI analysis · Informational 19/100

This commit rewrites a small part of the BitBox02 U2F feature from C to Rust. When you register or authenticate with an unknown website, the device shows a short mnemonic phrase instead of a site name. The change swaps the old libwally BIP39 library for the Rust bip39 crate to generate that phrase. It is a routine refactoring/porting change; there is no direct evidence it fixes or introduces a security vulnerability, though any rewrite can carry subtle bugs.

Security candidaterust: add bip39 dep and vendor itby Marko Bencun · f7f7fbe7 · Aug 26, 2025 · 29 filesMessage 45 · ThinInformational 18Details
Commit message · Marko Bencun

rust: add bip39 dep and vendor it

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 18/100

This commit adds a new software library (a BIP-39 implementation for handling recovery seed phrases) to the BitBox02 firmware and stores a copy of it inside the project's source tree (vendoring). It does not change any device behavior by itself; it is purely a dependency addition. There is no direct evidence in the commit of a security vulnerability, but adding a new dependency always slightly increases the attack surface and supply-chain risk.

Security candidatetest: unify unit-test/simulator mocks and fakes into libraryby Niklas Dusenlund · 919d157b · Aug 26, 2025 · 41 filesMessage 72 · AdequateInformational 15Details
Commit message · Niklas Dusenlund

test: unify unit-test/simulator mocks and fakes into library

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
seed or entropy path
AI analysis · Informational 15/100

This commit is a pure test-infrastructure refactoring. It merges duplicate mock and fake hardware-implementation files that previously existed separately for unit tests and the simulator into a single shared library called 'hardware-mocks'. It also adjusts Rust build flags so RTT logging only compiles for the real firmware target (target_os='none'). There is no change to the actual device firmware or to any security-critical runtime behavior.

Security candidatescreen: Abstract out oled functionsby Niklas Dusenlund · 72e8aa24 · Aug 21, 2025 · 15 filesMessage 72 · AdequateInformational 15Details
Commit message · Niklas Dusenlund

screen: Abstract out oled functions

The oled functionality needs to be an interface so that we can replace
those functions in a simulator

72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Explains rationale or failure mode
Why it was queued
boot or update path
AI analysis · Informational 15/100

This commit is a routine code cleanup that turns the screen drawing code into a generic interface so the same code can run on both the real device and a software simulator. It does not fix or introduce any security issue.

Security candidaterust/bitbox02/keystore: remove Bip39Wordlistby Marko Bencun · 2077f3d6 · Aug 20, 2025 · 3 filesMessage 60 · AdequateInformational 15Details
Commit message · Marko Bencun

rust/bitbox02/keystore: remove Bip39Wordlist

After the previous refactor, this became a thin wrapper, and is not
even wrapping any C function anymore.

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
secret or key material
AI analysis · Informational 15/100

This commit is a routine code cleanup. It removes a thin Rust wrapper type called Bip39Wordlist and replaces it with direct use of a plain list of word indices. The behavior of the BIP39 wordlist used for entering recovery words on the device stays the same; no security vulnerability is introduced or fixed.