Wallet password protection

[dkackman]

fix #206

[dkackman]

Code review

Found 2 issues:

1. Biometric unlock breaks after the first successful use — skipKeychainRef.current.add(fingerprint) is called every time the OS keychain returns a stored password (as a "pending validation" marker), but is never cleared when the backend accepts that password. It is only cleared in handleSubmit — the manual-entry path. In practice: the first biometric-authenticated operation succeeds, the flag stays set, and every subsequent operation in the same session skips the keychain and falls back to the password dialog. Biometric effectively works only once per session.

sage/src/contexts/PasswordContext.tsx

Lines 127 to 133 in 815e594

	const stored = await keychainGet(keychainKey(fingerprint));
	if (stored !== null) {
	// Mark as pending validation — if backend rejects, next call skips keychain
	skipKeychainRef.current.add(fingerprint);
	return stored;
	}
	// Fall through to password dialog if keychain retrieval fails

2. Delete confirmation dialog stays open when the password prompt is cancelled — setIsDeleteOpen(false) is only called at the bottom of deleteSelf, after the backend call. The early return on password === undefined (user cancels the password dialog) exits before that line, leaving the delete dialog stuck open. The Details dialog handles this correctly by calling setIsDetailsOpen(false) before the early return.

sage/src/components/WalletCard.tsx

Lines 81 to 92 in 815e594

	const deleteSelf = async () => {
	const password = await requestPassword(info.has_password);
	if (password === undefined) return;
	await commands
	.deleteKey({ fingerprint: info.fingerprint })
	.then(async () => {
	await clearKeychainEntry(info.fingerprint);
	setKeys(keys.filter((key) => key.fingerprint !== info.fingerprint));
	})
	.catch(addError);
	setIsDeleteOpen(false);
	};

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[dkackman]

@Hadamcik i merged 0.13 (ie main) into this PR. I'm not sure how (or if) key password protection interacts with apps or should interact with apps. Basically pre-apps, keys are encrypted at rest with a user secret and any operation that requires the keys, like singing, needs that password to retrieve the keys. Right now any app invocation back to sage that needs the keys will fail as it will have Password: none. So I think the question is how do apps solicit user input for the password or do they? Do they pass the password or expect sage to handle that prompting the user and the unlocking? I think I'd feel better about apps never prompting and that being the sage workflow. For now i put a placeholder in the brdging struct just to make it compile.

[Hadamcik]

Any app action can be gated by user approval and you can make it also conditional so you can ask for password there and that is Sage's not App's. App doesn't ask for that password and it doesn't get it.