archetech / archon / 29784082903

90%

main: 90%

push

github

fix: re-derive HD key when saving a different wallet than the cache (#733) (#757)

* fix: re-derive HD key when saving a different wallet than the cache (#733)

Restoring the unencrypted WalletFile form (as the MCP surface hands out
from create/show) into a long-lived instance whose HD-key cache was warmed
by a *different* wallet encrypted the restored metadata under the previous
wallet's key while storing the incoming wallet's mnemonicEnc. The stored
wallet became unreadable on next load, yet saveWallet returned true.

Root cause: the HD-key cache carried no record of which wallet's seed it
was derived from, so getHDKeyFromCacheOrMnemonic / _root_node returned a
stale key for the wallet being encrypted. The encrypted-restore path was
unaffected because it refreshes the cache before re-encrypting; only the
decrypted WalletFile path (which skips that refresh) was exposed. The CLI
is safe -- one command per process, cold cache -- which is why it never
surfaced.

Fix: key the cache to the passphrase-encrypted mnemonic (salt.iv.data) it
was derived from. getHDKeyFromCacheOrMnemonic / _root_node now re-derive
when the wallet being encrypted differs from the cached one. Normal
same-wallet saves keep the cache warm (no extra KDF); the KDF is paid only
when the wallet identity actually changes, which is correct.

Applied symmetrically to the JS core and the Python keymaster port (same
bug, same fix) to preserve parity. Adds a regression test in each that
warms an instance with wallet A, restores wallet B's decrypted form, and
asserts a fresh instance reads B back intact -- both fail without the fix.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: reuse HD-key cache across changePassphrase (JS parity)

Passphrase rotation re-encrypts the same mnemonic, so the cached HD key
stays valid. Repoint _hdkeyCacheKey to the new mnemonicEnc identity after
rotation so encryptWalletForStorage reuses the cache instead of paying an
extra PBKDF2... (continued)

2984 of 3535 branches covered (84.41%)

Branch coverage included in aggregate %.

8 of 8 new or added lines in 1 file covered. (100.0%)

6180 of 6606 relevant lines covered (93.55%)

840.8 hits per line