CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 11 Bitcoin

eth: prepare and generate proto files for data streaming

BB83be97ad View source ↗
Public commit record

What the developer wrote

Authored by Tomas Vrba

83/100 · Strong
eth: prepare and generate proto files for data streaming

update existing tests to include the new data length field

Adds new protobuf fields to support streaming large transaction data:
- data_length: Indicates total data size (triggers streaming mode if > 6144)
- EthSignDataRequestChunkResponse: Request for a data chunk at offset/length
- EthSignDataResponseChunkRequest: Response containing the requested chunk

Regenerates all protobuf files (Python, Rust, C) from the updated .proto.

Updates existing tests to populate the new data_length field (set to 0
for traditional mode where all data is sent inline).
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit adds new message definitions and generated code to support streaming large Ethereum transaction data in chunks, but it does not implement the actual streaming logic. Existing tests are updated only to include the new optional field set to zero, meaning the current behavior is unchanged. There is no indication this is a security fix or introduces a vulnerability.

Recommended action

No immediate security action required. Treat as a feature scaffolding commit. When the streaming implementation is added, review it carefully for bounds checking on offset/length, chunk size limits, memory exhaustion, and consistency between data_length and delivered chunks.

Security signals we found

01

New protobuf fields added for future streaming feature

02

Streaming request type explicitly rejected with InvalidState in current code

03

No validation or processing logic implemented for data_length or chunk messages

04

Tests only exercise data_length=0 (legacy inline-data mode)

Risk score

Why this scored 11/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 8/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.

More from BitBox02 firmware

Related watches

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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source commit ↗