#247 has landed. It tells the user of a non-master-xprv wallet, accurately, that their addresses "are still reachable by software that repeats the same non-standard derivation" — and in the same change it blocks Export Private Key for that wallet.
So the app names the recovery route and then withholds the only thing needed to take it. The user's key is sitting encrypted in our storage; no other copy exists unless they kept the original xprv.
Raised by the independent review of that PR. Blocking export is defensible and consistent with disabling signing — a defective wallet should not be handing out key material through a path whose error handling was written for a different case. But the combination is a dead end for the user, and this is a wallet, so a dead end means funds nobody can reach.
Options
(a) Offer the extended private key on this screen specifically, behind the password and behind copy that says what it is for. The user can then repeat the derivation elsewhere, which is exactly what the copy already tells them to do. Costs: an export path that exists only for a broken state, and a screen showing key material for a wallet we have declared defective.
(b) Offer the derived per-address private keys rather than the xprv. Narrower blast radius — one address at a time, no tree — and it is what the user actually needs to sweep funds. Costs more work: the derivation for these wallets is the non-standard one, so the export path has to reproduce the old broken derivation deliberately.
(c) Leave it blocked and change the copy to stop implying a recovery route we do not enable — say plainly that the addresses are reachable only if they still hold the original extended private key from elsewhere.
(d) Leave both as they are. The copy is technically true; a user who imported an xprv plausibly still has it.
Recommendation
(b), with (c) as the honest cheap option. Per-address keys are what someone recovering funds actually uses, and exporting them does not require trusting our broken tree — we derive, show, and the user sweeps. (a) hands over more than is needed. (d) leaves the app pointing at a door it locked.
Note this is only reachable by users who imported a non-master xprv before #210 landed, which may be nobody. If you believe that population is empty, (c) is clearly right and cheap.
Not blocking anything; #247 is merged and the current state is safe, just possibly a dead end.
https://git.eeqj.de/sneak/AutistMask/pulls/247 has landed. It tells the user of a non-master-`xprv` wallet, accurately, that their addresses "are still reachable by software that repeats the same non-standard derivation" — and in the same change it blocks Export Private Key for that wallet.
So the app names the recovery route and then withholds the only thing needed to take it. The user's key is sitting encrypted in our storage; no other copy exists unless they kept the original xprv.
Raised by the independent review of that PR. Blocking export is defensible and consistent with disabling signing — a defective wallet should not be handing out key material through a path whose error handling was written for a different case. But the combination is a dead end for the user, and this is a wallet, so a dead end means funds nobody can reach.
## Options
- **(a) Offer the extended private key on this screen specifically**, behind the password and behind copy that says what it is for. The user can then repeat the derivation elsewhere, which is exactly what the copy already tells them to do. Costs: an export path that exists only for a broken state, and a screen showing key material for a wallet we have declared defective.
- **(b) Offer the derived per-address private keys** rather than the xprv. Narrower blast radius — one address at a time, no tree — and it is what the user actually needs to sweep funds. Costs more work: the derivation for these wallets is the non-standard one, so the export path has to reproduce the old broken derivation deliberately.
- **(c) Leave it blocked and change the copy** to stop implying a recovery route we do not enable — say plainly that the addresses are reachable only if they still hold the original extended private key from elsewhere.
- **(d) Leave both as they are.** The copy is technically true; a user who imported an xprv plausibly still has it.
## Recommendation
**(b)**, with **(c)** as the honest cheap option. Per-address keys are what someone recovering funds actually uses, and exporting them does not require trusting our broken tree — we derive, show, and the user sweeps. (a) hands over more than is needed. (d) leaves the app pointing at a door it locked.
Note this is only reachable by users who imported a non-master xprv before https://git.eeqj.de/sneak/AutistMask/issues/210 landed, which may be nobody. If you believe that population is empty, **(c)** is clearly right and cheap.
Not blocking anything; https://git.eeqj.de/sneak/AutistMask/pulls/247 is merged and the current state is safe, just possibly a dead end.
sneak
was assigned by clawbot2026-08-12 10:42:58 +02:00
Settled, option (c), as recorded in the review of open decisions on 7 October: export stays blocked for this wallet, and the copy stops pointing at a recovery route the app does not offer. It is the cheap, honest option and easy to reverse.
Plan: rewrite the second paragraph of the notice in src/shared/walletDefects.js to say plainly that the funds at these addresses can be reached only with the original extended private key, if the user still holds it, in software that repeats the same derivation; signing stays disabled; no other behaviour changes. The test that pins the notice text is updated.
Model: opus-5-5
Settled, option (c), as recorded in the review of open decisions on 7 October: export stays blocked for this wallet, and the copy stops pointing at a recovery route the app does not offer. It is the cheap, honest option and easy to reverse.
Plan: rewrite the second paragraph of the notice in `src/shared/walletDefects.js` to say plainly that the funds at these addresses can be reached only with the original extended private key, if the user still holds it, in software that repeats the same derivation; signing stays disabled; no other behaviour changes. The test that pins the notice text is updated.
Model: opus-5-5
sneak
was unassigned by clawbot2026-10-14 03:59:18 +02:00
clawbot
self-assigned this 2026-10-14 03:59:18 +02:00
Built as #514. The notice now says that the addresses can be reached only with the extended private key the user imported, if they kept a copy of it, and lists private key export among the disabled controls alongside signing and sending. Nothing else changes.
Model: opus-5-5
Built as https://git.eeqj.de/sneak/AutistMask/pulls/514. The notice now says that the addresses can be reached only with the extended private key the user imported, if they kept a copy of it, and lists private key export among the disabled controls alongside signing and sending. Nothing else changes.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
#247 has landed. It tells the user of a non-master-
xprvwallet, accurately, that their addresses "are still reachable by software that repeats the same non-standard derivation" — and in the same change it blocks Export Private Key for that wallet.So the app names the recovery route and then withholds the only thing needed to take it. The user's key is sitting encrypted in our storage; no other copy exists unless they kept the original xprv.
Raised by the independent review of that PR. Blocking export is defensible and consistent with disabling signing — a defective wallet should not be handing out key material through a path whose error handling was written for a different case. But the combination is a dead end for the user, and this is a wallet, so a dead end means funds nobody can reach.
Options
Recommendation
(b), with (c) as the honest cheap option. Per-address keys are what someone recovering funds actually uses, and exporting them does not require trusting our broken tree — we derive, show, and the user sweeps. (a) hands over more than is needed. (d) leaves the app pointing at a door it locked.
Note this is only reachable by users who imported a non-master xprv before #210 landed, which may be nobody. If you believe that population is empty, (c) is clearly right and cheap.
Not blocking anything; #247 is merged and the current state is safe, just possibly a dead end.
Settled, option (c), as recorded in the review of open decisions on 7 October: export stays blocked for this wallet, and the copy stops pointing at a recovery route the app does not offer. It is the cheap, honest option and easy to reverse.
Plan: rewrite the second paragraph of the notice in
src/shared/walletDefects.jsto say plainly that the funds at these addresses can be reached only with the original extended private key, if the user still holds it, in software that repeats the same derivation; signing stays disabled; no other behaviour changes. The test that pins the notice text is updated.Model: opus-5-5
Built as #514. The notice now says that the addresses can be reached only with the extended private key the user imported, if they kept a copy of it, and lists private key export among the disabled controls alongside signing and sending. Nothing else changes.
Model: opus-5-5