Fixes #510. Sending, site transactions, site signatures and private key export derived the key at the address's position in the wallet's list, not at the index the address was derived at. After an import whose scan passes over an unused index, or after removing an address that is not the last, the screen named one address and the wallet used another address's key.
What changed:
Each HD and xprv address record stores index: 0 at wallet creation, the scan's index on import, nextIndex when "+" adds one.
getSignerForAddress() takes the address record instead of a list position, derives at its index, and refuses with a full sentence when the key's address is not the record's.
The export screen shows that refusal instead of "That password is incorrect."
README: Data Model names the field; ExportPrivKey lists the refusal.
What the diff does not show:
An HD or xprv record without index is now refused. Every creation path sets it; hand-built test wallets that sign needed index: 0.
tests/addressKey.test.js drives the real import scan, "+", address removal and the confirmation, signature approval and export screens. Without this change its key checks fail with the keys the report describes.
Disclosures:
Judgement call: the address check also applies to private-key wallets, which have no index.
Judgement call: the send screen checks the key against the selected address's record, which its From line is built from; a refusal there goes to the error screen, as the non-master xprv refusal already does.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/510. Sending, site transactions, site signatures and private key export derived the key at the address's position in the wallet's list, not at the index the address was derived at. After an import whose scan passes over an unused index, or after removing an address that is not the last, the screen named one address and the wallet used another address's key.
What changed:
- Each HD and xprv address record stores `index`: 0 at wallet creation, the scan's index on import, `nextIndex` when "+" adds one.
- `getSignerForAddress()` takes the address record instead of a list position, derives at its `index`, and refuses with a full sentence when the key's address is not the record's.
- The export screen shows that refusal instead of "That password is incorrect."
- README: Data Model names the field; ExportPrivKey lists the refusal.
What the diff does not show:
- An HD or xprv record without `index` is now refused. Every creation path sets it; hand-built test wallets that sign needed `index: 0`.
- `tests/addressKey.test.js` drives the real import scan, "+", address removal and the confirmation, signature approval and export screens. Without this change its key checks fail with the keys the report describes.
Disclosures:
- Judgement call: the address check also applies to private-key wallets, which have no index.
- Judgement call: the send screen checks the key against the selected address's record, which its From line is built from; a refusal there goes to the error screen, as the non-master xprv refusal already does.
Model: opus-5-5
Sending, site transactions, site signatures and private key export
derived the key at the address's position in the wallet's list. After
an import whose scan passed over an unused index, or after removing an
address that was not the last, that position named another address's
key.
Each HD and xprv address record now stores the index it was derived at
(at wallet creation, by the import scan, by "+"), and
getSignerForAddress() derives at that index and refuses any key whose
address differs from the record's. The export screen reports that
refusal instead of calling the password wrong.
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.
Fixes #510. Sending, site transactions, site signatures and private key export derived the key at the address's position in the wallet's list, not at the index the address was derived at. After an import whose scan passes over an unused index, or after removing an address that is not the last, the screen named one address and the wallet used another address's key.
What changed:
index: 0 at wallet creation, the scan's index on import,nextIndexwhen "+" adds one.getSignerForAddress()takes the address record instead of a list position, derives at itsindex, and refuses with a full sentence when the key's address is not the record's.What the diff does not show:
indexis now refused. Every creation path sets it; hand-built test wallets that sign neededindex: 0.tests/addressKey.test.jsdrives the real import scan, "+", address removal and the confirmation, signature approval and export screens. Without this change its key checks fail with the keys the report describes.Disclosures:
Model: opus-5-5
7b731ea261toa456170145a456170145to4b6390bad7View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.