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

chore(core/tools): drop bootloader_hashes for boot_ucb models

Public commit record

What the developer wrote

Authored by tychovrahe

100/100 · Strong
chore(core/tools): drop bootloader_hashes for boot_ucb models

UCB models verify a staged bootloader through its PQ boot-header
signature (boot_image_replace under USE_BOOT_UCB), not through the padded
blake2s digests in bootloader_hashes.h -- boot_image_embdata.c only wires
.hash_00/.hash_FF `#ifndef USE_BOOT_UCB`, and that file is compiled only
by the firmware project, which enables boot_ucb for these models. The
digests are therefore never referenced for UCB models; the generated
header only churned whenever the bootloader binary changed, for no
consumer.

Skip generation for boot_ucb models (detected from the model.toml
features list), remove the now-dead #include from their model headers,
and delete the stale generated files for T3W1, D002 and T3T2.

[no changelog]

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This is a cleanup change that stops generating unused bootloader hash files for newer Trezor models (D002, T3T2, T3W1). These models already verify the bootloader using a different mechanism (UCB with post-quantum signatures), so the old hash files were never actually used. The commit deletes the stale files and removes their #include references. There is no security vulnerability here.

Recommended action

No security action required. This is a benign cleanup. Reviewers may verify that no non-UCB models accidentally had their bootloader_hashes.h removed and that the generation script correctly identifies boot_ucb from model.toml.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 10/10
Evidence quality 5/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.