ConvertToKeycardAccount saves KeycardPairing before password check

[glitchminer]

Not reachable from the Status client.
The client verifies the password before calling (AuthenticationPopup.qml:36-38). Filing this as an API-boundary observation, not a user-facing bug.

What happens:
ConvertToKeycardAccount writes the keycard pairing to the multiaccounts DB as its first action, before anything is validated. If a later step fails, that write is not rolled back.

pkg/backend/geth_backend.go:1311 saves account.KeycardPairing. The next call, ensureDBsOpened (:1316), passes oldPassword down but never uses it while a session is open — ensureAppDBOpened (:532) and ensureWalletDBOpened (:592) both return early when the DB handle is already set. So the first real password check happens later, inside the keypair migration.

After a failed call, RefersToKeycard() returns true for an account that is not on a keycard.

Steps to reproduce
(Go test calling the backend directly: not a client flow)

1. Log in to a password-based profile.
2. Call ConvertToKeycardAccount with an account whose KeycardPairing is set and a wrong oldPassword.
3. Read the account back from the multiaccounts DB.

Observed (develop bd4201f95):
the call returns an error, keystore files are intact, the keypair
is not migrated — but GetAccount(keyUID).KeycardPairing holds the new pairing value.

Suggested:
write the pairing after validation, or roll it back on failure.

Close this if the team's position is that callers own validation.

[saledjenic]

@glitchminer this issue does not apply to the app. There is no in-app use case that would make such a call, since some pre-checks/validations are done on the UI side. Also, not all status-go endpoints should be treated as endpoints that can be called individually and tested separately, even though status-go is used as a lib.

Please retest the issue and share the steps on how it can be reproduced in the app.

[glitchminer]

Can't be reproduced in the app, you're right. The password is verified before this call happens: AuthenticationPopup.qml:36-38 runs verifyPassword() and only emits on success, and d.authenticationPassword is set in one place from that signal (KeycardManagementPopup.qml:971).

I've rewritten the body at API level. What's left is just that the pairing is written before anything is validated, and isn't rolled back if a later step fails. It can be closed if that's not worth hardening.

[sunleos]

Hey folks, checked the latest comments and based on them, moved it to the could-have bucker of v2.40.
Feel free to move it back if there is anything important to fix in v2.39, or close it entirely if the scope now got clarified.