grenade pushed 2 commits to quantus/ui:main

• 160d97c build: declare @quantus/crypto as a ui-keyring dev dependency
• c7c23b7 feat!: ui-keyring holds post-quantum keys only

grenade pushed 1 commit to quantus/ui:pq-only

• 160d97c build: declare @quantus/crypto as a ui-keyring dev dependency

grenade pushed to quantus/ui:pq-only

grenade commented on #1 in quantus/ui

Verified against `main` (`2d6a9ad1`), closing. - **Restored address is right:** fixed in `ec1399f3`. `restoreAccount` passes the stored account id rather than inventing a public key, the same…

Verified against main (2d6a9ad1), closing.

• Restored address is right: fixed in ec1399f3. restoreAccount passes the stored account id rather than inventing a public key, the same approach as common's createFromJson. An extension-exported ML-DSA JSON restores to the same address and can sign (Keyring.dilithium.spec.ts).
• Tampering is caught: a JSON whose address does not match its key is rejected.
• Address stable across unlock: checked in common's dilithiumJson.spec.ts, since restoreAccount unlocks immediately.
• Upstream files unchanged: sr25519 restore is pinned, and ed25519 still takes the unchanged branch until quantus/common#6 removes it.

grenade closed issue #1 in quantus/ui

grenade pushed 4 commits to quantus/ui:main

• 2d6a9ad build: consume the forks at 14.0.3-quantus.2
• 18105d3 build: pin the forked packages at 14.0.3-quantus.1
• f2a1ab3 build: consume the forked @polkadot packages from the registry, drop the scaffolding
• ec1399f fix(ui-keyring): restoreAccount cannot rebuild an ML-DSA public key from an address

grenade pushed 1 commit to quantus/ui:quantus-restore-account

• 2d6a9ad build: consume the forks at 14.0.3-quantus.2

grenade pushed 1 commit to quantus/ui:quantus-restore-account

• 18105d3 build: pin the forked packages at 14.0.3-quantus.1

grenade pushed 1 commit to quantus/ui:quantus-restore-account

• f2a1ab3 build: consume the forked @polkadot packages from the registry, drop the scaffolding

grenade commented on #1 in quantus/ui

Done, on `quantus-restore-account` (`ec1399f3`). 5 specs; 46 tests pass repo-wide, build clean. ## The fix Exactly as this issue framed it — solved in quantus/common#3 first, then mirrored.…

Done, on quantus-restore-account (ec1399f3). 5 specs; 46 tests pass repo-wide, build clean.

The fix

Exactly as this issue framed it — solved in quantus/common#3 first, then mirrored. restoreAccount now passes an accountId rather than a public key it cannot have:

const info = isDilithium(cryptoType)
  ? { accountId: raw, publicKey: new Uint8Array(), secretKey: new Uint8Array() }
  : { publicKey: raw };

createPair uses it for the address while locked and clears it once decodePkcs8 supplies the real key — checking the two agree on the way. That check earns its place here for the same reason as in the keyring: the address sits outside the encrypted blob, so a tampered one decodes cleanly and yields an account displaying an address its key cannot sign for. Pinned by a test.

The 'ed25519' fallback for version-0 JSON is left as-is and commented. Those files predate the crypto type being recorded and are by definition not Quantus, so the guess is safe — but quantus/common#6 removes ed25519 from KeypairType, at which point it has to become a refusal.

Acceptance

• [x] a JSON file exported by the extension restores to an account with the same address
• [x] the address reported before unlock matches the address after unlock
• [x] upstream-format sr25519 files restore unchanged
• [x] the restored account can sign, and the signature verifies against its address

The cross-repo linking has run out of road

Getting this repo to see the forked common took four separate fixes, each for the same underlying cause: node resolves a portal/link symlink to its realpath, after which @polkadot/util-crypto resolves inside common's tree — where it is the workspace source directory, with no exports map.

1. resolutions pointing the four @polkadot packages at common's build output
2. tsconfig.base.json path mappings, with the *.d.ts substitution first, because NodeNext will not infer an extension for a bare path and looks for a types directory instead of types.d.ts
3. tsconfig.json overriding those with the runtime .js view, because @polkadot/dev-ts reads that file and would otherwise import a declaration file as a module — "Debug Failure. Output generation failed"
4. --preserve-symlinks in the test script, which yarn itself warns is required for portals

All four are dev-time scaffolding for a problem that does not exist once these packages come from a registry. This is the third repo to hit it (common → @quantus/crypto, now ui → common), and the extension will be the fourth with more dependencies than any of them.

quantus/extension#2 is now the blocking item, not a tidy-up. Publishing to the Gitea npm registry needs a token, which I cannot create — so it needs a hand. Until then every downstream repo pays this tax again.

One incidental result worth recording: yarn lint errors dropped from 25 to 8. The tsconfig mappings resolved types that were previously any, removing a pile of no-unsafe-assignment. The remaining 8 are upstream's own, in loadContract and allowGenesis, and are left alone per the rebasability convention — note that yarn lint therefore still exits non-zero on this repo, as it does on pristine upstream.

grenade pushed 1 commit to quantus/ui:quantus-restore-account

• ec1399f fix(ui-keyring): restoreAccount cannot rebuild an ML-DSA public key from an address

grenade opened issue #1 in quantus/ui

ui-keyring: restoreAccount cannot rebuild a Quantus public key from an address