rob thijssen c7c23b7958 feat!: ui-keyring holds post-quantum keys only ...

Follows quantus/common#6, which removed ed25519, sr25519, ecdsa and ethereum
from the keyring (forks at 14.0.3-quantus.3).

- restoreAccount now goes through keyring.createFromJson instead of building
  the pair itself. A restored backup therefore gets the same refusal as every
  other entry point: a polkadot{.js} export of an sr25519 or ed25519 account is
  told "<type> keys are not quantum-safe and cannot be held here", not decoded.
- Version-0 JSON, which does not record its key type and so cannot be ML-DSA,
  is refused. Upstream guessed ed25519.
- isEthereum is always false; it's kept so callers written against upstream
  still read a boolean.
- loadAll already skips, with a warning, any stored account the keyring
  refuses, so a profile holding an old classical account still starts.

The spec that pinned sr25519 restore as unchanged is replaced by the two
refusals. ui-keyring 3.16.7-quantus.3, on the quantus.3 forks. yarn test 47
passing; lint clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012uDUodEcRbBwNRi3UCmw8f

2026-09-16 21:13:01 +03:00

1.6 KiB

Raw Permalink Blame History

View Raw