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

workflow: allow displayable UTF-8 messages

Public commit record

What the developer wrote

Authored by NickeZ Agent

78/100 · Adequate
workflow: allow displayable UTF-8 messages

Accented message text is encoded as hex or rejected even when the
BitBox02 fonts can display it. Show safe UTF-8 messages directly when
the confirmation font contains every glyph, retaining the hex
fallback for malformed or unsupported message bytes.

Apply the same character rules to Ethereum typed strings and payment
request memos. Reject typed strings when the display font lacks a
glyph, and cover accepted Unicode, unsafe characters, and missing
glyphs in the workflow tests.
✓ 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 changes how the BitBox02 hardware wallet decides whether to show a message to the user as readable text or as hex. Previously, only plain ASCII was shown as text; accented characters and other UTF-8 were always shown as hex. Now the device checks whether each character exists in its display font. If every character can be drawn, the message is shown normally; otherwise it falls back to hex. The same font check is also applied to Ethereum typed-message strings and payment-request memos, which now reject unsupported characters instead of accepting them. The change is a user-experience improvement with a small security angle: it reduces the chance that a user is confused by hex-encoded text that they cannot read, and it prevents attackers from sneaking in invisible or misleading characters in contexts where they were previously accepted.

Recommended action

Treat as a routine defensive-hardening commit. Review the `has_glyph` implementation and font coverage to ensure the Regular11 font truly contains all intended safe glyphs and that the mock used in tests matches the real device font. Verify that callers of `verify_message` and the Ethereum/payment-request APIs handle `Error::InvalidInput` gracefully and do not leak state after partial validation.

Security signals we found

01

Replaces ASCII-only display logic with font-glyph coverage validation

02

Prevents display of unreadable hex for supported UTF-8 characters

03

Rejects unsupported/invisible characters in Ethereum typed strings and payment memos

04

Removes unsafe `from_utf8_unchecked` in message verification

05

Adds tests for invisible/disruptive Unicode characters (tab, non-breaking space, soft hyphen, CJK, malformed bytes)

Risk score

Why this scored 36/100

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