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

qml: strip whitespace from message before signing, as in qt gui

Public commit record

What the developer wrote

Authored by Ferdinando Ametrano

96/100 · Strong
qml: strip whitespace from message before signing, as in qt gui

The qt gui strips leading/trailing whitespace from the message (and
address) both when signing and when verifying (see #4327). The qml gui
already strips in verifyMessage (qedaemon.py), but not in signMessage:
a message with leading/trailing whitespace signed in the qml gui would
produce a signature that fails verification even in the same dialog.

Strip in signMessage too, replicating the qt gui behaviour.

related: https://github.com/spesmilo/electrum/issues/4327
related: https://github.com/btclib-org/btclib/issues/200

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit fixes a minor consistency bug in Electrum's newer QML (mobile-style) user interface. When signing a message, the app now removes accidental spaces at the start or end of the message and address, just like the older desktop Qt interface already did. Without this fix, a message signed in the QML interface could fail verification because of stray whitespace. It is a usability/reliability fix, not a serious security vulnerability.

Recommended action

No urgent action needed. Treat as a normal bugfix/UX consistency patch. Users relying on message signing in the QML GUI should update to a release containing this commit to avoid verification failures caused by whitespace.

Security signals we found

01

Behavioral inconsistency between GUI implementations could cause user confusion or failed verification

02

No cryptographic weakness introduced; change is input normalization

03

No memory-unsafe code, no privilege changes, no network changes

Risk score

Why this scored 19/100

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