57e1fd0198
All checks were successful
check / check (push) Successful in 38s
Two ways an xprv import could silently produce a wallet that is not the user's, with no error shown. Checksum: ethers' HDNodeWallet.fromExtendedKey skips base58 checksum verification when the decoded payload is the usual 82 bytes, which is exactly the case the checksum exists to catch. Every extended key now goes through parseExtendedKey, which re-encodes the parsed node and requires the round trip to reproduce the input exactly. Over every single-character substitution of the BIP-32 vector 1 master key, 199 parsed before and 0 parse now; the xpub path shared the hole (101 accepted typos) and is fixed by the same helper. Depth: hdWalletFromXprv and getSignerForAddress derived the relative path 44'/60'/0'/0, which is the BIP-44 Ethereum account path only for a depth-0 master key. Under an account-level (depth-3) key it derived m/44'/60'/0'/44'/60'/0'/0 instead of refusing. Both now derive the absolute BIP44_ETH_PATH from a key checked to be at depth 0. The extended-key format carries depth, parent fingerprint and child index but not the path a key sits at, so a non-master key cannot be placed in the tree without guessing; it is rejected, and the import screen says an account-level or child key is not supported. Import errors are full sentences per the README Language & Labeling rules, and the skipped one-character-typo test is unskipped.