Repository navigation
Verify recovered wallet identity before import #26
Description
Accident-safety finding. src/codex32_gui/pages.py::_record() could import private descriptors before the restore flow authenticated the recovered seed as the wallet the operator intended.
Required behavior before any wallet mutation:
- First-class evidence: if the operator has the seed-keyed encrypted descriptor backup tracked in wallet: Encrypted descriptor backup keyed by the seed #55, decrypt it with the recovered seed and require the recovered seed to match the backed-up single-sig descriptors.
- Second-class recovery record: otherwise accept a matching typed master fingerprint and/or the recorded single-sig descriptor checksum. These are human-scale accident checks, not a defense against a malicious party who can replace a threshold of shares.
- No wallet record: explicitly offer a fallback that displays the recovered fingerprint plus the codex32/Bails identifier result, then asks the operator to confirm before import. This is deliberately a visual accident check because older/Bails backups may not have a recorded fingerprint and Bails alpha used a different identifier rule.
#57 implements the current release-gate subset for the CLI/library: typed fingerprint plus explicit no-record fallback, with the check enforced before wallet mutation. #81 strengthens ms32 create --existing by moving the record/no-record decision before any new share ceremony. #118 is the focused clean GUI replay of the same accident-safety boundary. Historical #28 must not be merged because its old branch duplicates library history.
#42 is integrated into reviewability-v1. The remaining library/CLI integration order is #57 → #105 → #99 → #80 → #81 → #95. All five current heads have current-head Codex release-gate ACKs; their exact-head Python-package runs are green, and the applicable restore/Core heads also have green Bitcoin Core fixture runs. #105/#80/#81/#95 are agent-authored follow-ups and still require the repository's responsible-human rewrite/squash step before integration.
Final GUI integration: after that library/CLI candidate and the remaining foundation/security/API work settle, rebase the clean GUI stack once in order #65 → #66 → #77 → #78, then replay/squash the single focused GUI restore-authentication commit from #118 onto that tip. Do not merge the disposable staging base used by #118 or preserve the duplicated library snapshot and exploratory history from #28. Run the supported Tails guest-resolution/manual qualification, including the unresolved #76 artwork observation, and then include the GUI in the fresh adversarial review.
#43 tracks checksummed/type-back wallet-record metadata. #55 separately tracks the stronger encrypted-descriptor evidence and malicious-tampering defense; it requires human planning/review before implementation rather than an automatic PR.
Activity
wallet: Require the recorded fingerprint before import
BenWestgate commentedon Sep 24, 2026
I agree. The software should either verify the wallet from the descriptor or encrypted descriptor backup (meaning it's encrypted/signed by a key the valid master node derives), request the fingerprint be entered (useful for QR + passphrase share recoveries w/ inadequate salt and error detection), or display the fingerprint for user confirmation.
Even if the I don't have a fingerprint case, I'd still show it first and ask if this was it before guessing the wallet is right.
Update Core integration callers
wallet: Require the recorded fingerprint before import
wallet: Require the recorded fingerprint before import
wallet: Require the recorded fingerprint before import
wallet: Require the recorded fingerprint before import
wallet: Require the recorded fingerprint before import