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

gate the display address, sign message and keystore discovery panes on a fingerprint resolved after pin entry

Public commit record

What the developer wrote

Authored by Craig Raw

50/100 · Thin
gate the display address, sign message and keystore discovery panes on a fingerprint resolved after pin entry
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit changes how Sparrow Wallet checks that a connected hardware wallet is the correct one before letting the user display a receiving address, sign a message, or discover keystores. Previously, the app disabled the relevant buttons if the device's reported fingerprint did not match the wallet. The problem is that a PIN-protected device reports no fingerprint until after the PIN is entered, so the old check happened too early and could be bypassed. The new code waits until after PIN entry, re-enumerates the device to get its real fingerprint, and only then enables or disables the button. This prevents a user from accidentally using the wrong hardware wallet and, for example, displaying or signing with keys that do not belong to their wallet.

Recommended action

Review the lark submodule bump (13001e8acf7048a15c81cc050c65e6e164c3aa33) for related security changes, and verify that the onFailed re-enumeration path does not enable operations when the fingerprint could not be resolved. Consider adding explicit user-facing warnings when a fingerprint mismatch is detected after unlock.

Security signals we found

01

Fingerprint-based device authorization moved from pre-unlock to post-unlock

02

PIN-protected devices re-enumerated after PIN entry to obtain authoritative fingerprint

03

Display address, sign message, and keystore discovery now disabled if device fingerprint does not match wallet

04

Comment explicitly notes risk of silently persisting mismatched keystores during discovery

05

Potential UI race or silent enablement if re-enumeration fails (onFailed still calls showUnlockedOperation)

Risk score

Why this scored 59/100

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