feat: add OneKey keyring #353
Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Akaryatrh
force-pushed
the
feat/onekey-keyring
branch
from
2dc83be to
a18c779
Compare
Akaryatrh
added
the
team-hardware-wallets
|
@metamaskbot publish-preview |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions. |
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions. |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions. |
|
@metamaskbot publish-preview |
2 similar comments
|
@metamaskbot publish-preview |
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions. |
|
@SocketSecurity ignore npm/secure-json-parse@4.1.0 |
Akaryatrh
force-pushed
the
feat/onekey-keyring
branch
from
f0a1825 to
7d43e97
Compare
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions. |
| page = 0; | ||
|
|
||
| perPage = 5; | ||
|
|
||
| unlockedAccount = 0; | ||
|
|
||
| hdk = new HDKey(); | ||
|
|
||
| accounts: readonly Hex[] = []; | ||
|
|
||
| accountDetails: Record<string, AccountDetails> = {}; | ||
|
|
||
| passphraseState: string | undefined; | ||
|
|
||
| hdPath = defaultHdPath; | ||
|
|
||
| network: NetworkApiUrls = NetworkApiUrls.Mainnet; | ||
|
|
||
| implementFullBIP44 = false; |
There was a problem hiding this comment.
Can we make these properties sharp, and readonly where possible?
| lock(): void { | ||
| this.hdk = new HDKey(); | ||
| } | ||
|
|
||
| isUnlocked(): boolean { | ||
| return Boolean(this.hdk?.publicKey); | ||
| } |
There was a problem hiding this comment.
Why do we need this locking mechanism internal to the keyring? What does this lock represent?
There was a problem hiding this comment.
lock, isUnlocked
These two are designed to optimize the user experience of our hardware passphrase functionality.
Without them, users would need to re-enter the passphrase every time. We lock when entering the connect wallet page, then have the device re-enter the passphrase. This ensures that scenarios like address pagination won't trigger passphrase re-entry.
There was a problem hiding this comment.
hmm the only thing I see this doing is removing the cached HD public key coming from the device. Though .lock is not a common method that other hardware keyrings have, and we'd have to add specific code on clients to be call this function on the OneKey keyring. I was wondering if we really need this mechanism instead of just relying on usual patterns we have on other keyrings, where the "lock" is coming from KeyringController in the form of destroying keyring instances altogether
| return Promise.resolve(); | ||
| } | ||
|
|
||
| getModel(): string | undefined { |
There was a problem hiding this comment.
Is/will this method used somewhere? If not, it can be removed.
There was a problem hiding this comment.
used to distinguish equipment models.
Akaryatrh
force-pushed
the
feat/onekey-keyring
branch
from
7d43e97 to
be5d34b
Compare
| } | ||
| const signature = addHexPrefix(response.payload.signature); | ||
| // eslint-disable-next-line promise/no-multiple-resolved | ||
| resolve(signature); |
There was a problem hiding this comment.
Bug: Missing return after reject causes double promise resolution
In signPersonalMessage, when the address verification fails (lines 410-414), reject() is called but execution continues without a return statement. This causes resolve(signature) to also be called on line 418. The // eslint-disable-next-line promise/no-multiple-resolved comment explicitly acknowledges this issue. While Promise semantics cause the first call (reject) to take effect, the control flow is broken—the code after reject() still runs unnecessarily. The similar signTypedData method correctly handles this case by using throw instead, which properly exits the function.
There was a problem hiding this comment.
Cursor is right here, you should remove the // eslint-disable-next-line and put the resolve in a else {} block.
Akaryatrh
force-pushed
the
feat/onekey-keyring
branch
2 times, most recently
from
a9761e5 to
8508712
Compare
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions. |
| reject(new Error('signature doesnt match the right address')); | ||
| } | ||
| // eslint-disable-next-line promise/no-multiple-resolved | ||
| resolve(signature); |
There was a problem hiding this comment.
Bug: Missing return after reject causes dual promise settlement
In signPersonalMessage, when the recovered address doesn't match the expected account, reject() is called but execution continues without returning. This causes resolve(signature) on line 427 to also be called. The eslint-disable-next-line promise/no-multiple-resolved comment explicitly suppresses the linter warning about this issue rather than fixing it. While Promise semantics make only the first settlement effective, calling both reject() and resolve() is a control flow error indicating the code doesn't properly stop execution after detecting the address mismatch.
| async dispose(): Promise<void> { | ||
| this.sdk?.dispose(); | ||
| return Promise.resolve(); | ||
| } |
There was a problem hiding this comment.
Bug: Dispose leaves bridge in inconsistent reinitialization state
The dispose() method calls this.sdk?.dispose() but doesn't reset isSDKInitialized or sdk. When keyring.destroy() calls bridge.dispose(), the bridge is left in an inconsistent state where isSDKInitialized remains true and sdk still references the disposed SDK. If init() is called afterward, it returns early because isSDKInitialized is true, preventing reinitialization. Subsequent operations will then use the disposed SDK. The destroy() method properly resets state but is never called by the keyring.
Additional Locations (1)
There was a problem hiding this comment.
Cursor's comment here make sense. We should add this.isSDKInitialized = false;.
| return await this.sdk | ||
| .evmGetPublicKey('', '', { ...params, skipPassphraseCheck: true }) | ||
| .then((result) => { |
There was a problem hiding this comment.
Can we avoid mixing .then().catch() with async/awaits? Can we use async/await only to improve readability?
| }, | ||
| }; | ||
| } | ||
| return await this.sdk.getPassphraseState('').then((result) => { |
There was a problem hiding this comment.
similar to my other comment, can we use a more consistent pattern with promises?
| ...params, | ||
| skipPassphraseCheck: true, | ||
| }) | ||
| .then((result) => { |
There was a problem hiding this comment.
similar to other comments, can we use async/await only?
| ...params, | ||
| skipPassphraseCheck: true, | ||
| }) | ||
| .then((result) => { |
| ...params, | ||
| skipPassphraseCheck: true, | ||
| }) | ||
| .then((result) => { |
Akaryatrh
force-pushed
the
feat/onekey-keyring
branch
from
8508712 to
2d94f20
Compare
| reject(new Error('signature doesnt match the right address')); | ||
| } | ||
| // eslint-disable-next-line promise/no-multiple-resolved | ||
| resolve(signature); |
There was a problem hiding this comment.
Bug: Missing return after reject causes promise to resolve erroneously
In signPersonalMessage, when the signature address doesn't match the expected account, reject() is called but execution continues and resolve() is also called on line 427. The eslint-disable comment for promise/no-multiple-resolved acknowledges this issue but doesn't fix it - a return statement is needed after the reject() call. This causes the promise to resolve with the signature even when it should be rejected, allowing invalid signatures to be returned to callers.
| { | ||
| debug: false, | ||
| fetchConfig: false, | ||
| connectSrc: 'https://jssdk.onekey.so/1.1.0/', |
There was a problem hiding this comment.
Bug: Test expects wrong SDK version in connectSrc assertion
The test asserts that init() is called with connectSrc: 'https://jssdk.onekey.so/1.1.0/', but the actual implementation in onekey-web-bridge.ts uses version 1.1.17 ('https://jssdk.onekey.so/1.1.17/'). This version mismatch will cause the test to fail since the expected connectSrc value doesn't match what the code actually passes.
Akaryatrh
force-pushed
the
feat/onekey-keyring
branch
from
2d94f20 to
07316d7
Compare
| reject(new Error('signature doesnt match the right address')); | ||
| } | ||
| // eslint-disable-next-line promise/no-multiple-resolved | ||
| resolve(signature); |
There was a problem hiding this comment.
Bug: Missing return after reject causes promise multiple resolution
In signPersonalMessage, when the signature address verification fails, reject() is called but execution continues to also call resolve(signature) because there's no return statement. This causes both rejection and resolution of the same promise. The eslint-disable comment promise/no-multiple-resolved acknowledges this issue was suppressed rather than fixed. Compare to signTypedData which correctly uses throw for the same scenario. This could cause the potentially invalid signature to be returned despite the verification failure.
Akaryatrh
force-pushed
the
feat/onekey-keyring
branch
from
07316d7 to
ca02a28
Compare
| reject(new Error('signature doesnt match the right address')); | ||
| } | ||
| // eslint-disable-next-line promise/no-multiple-resolved | ||
| resolve(signature); |
There was a problem hiding this comment.
Bug: Missing return after reject causes both reject and resolve
In signPersonalMessage, when the signature address verification fails (lines 420-424), reject() is called but execution continues to resolve(signature) on line 427 because there's no return statement after the reject(). The ESLint comment promise/no-multiple-resolved explicitly acknowledges this issue but suppresses the warning rather than fixing it. While the promise will technically reject (since reject is called first), both reject and resolve are invoked in the same code path, which indicates unintended control flow.
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions. |
Adds OneKey keyring based on OneKey libraries.
Note
Introduce
@metamask/eth-onekey-keyringwith OneKey hardware wallet support via a web bridge, and wire it into the monorepo.packages/keyring-eth-onekeyOneKeyKeyring(src/onekey-keyring.ts) with account paging, HD path management, and signing (signTransaction,signPersonalMessage,signTypedData).OneKeyWebBridge(src/onekey-web-bridge.ts) wrapping@onekeyfe/hd-web-sdk, handling UI events, passphrase state, and transport switching.src/index.ts; config files added (package.json,jest.config.js,tsconfig*.json,typedoc.json,README.md,CHANGELOG.md,LICENSE).onekey-keyring.test.ts,onekey-web-bridge.test.ts.README.mdpackage list and dependency graph to include@metamask/eth-onekey-keyring.tsconfig.jsonandtsconfig.build.json.yarn.lockfor new dependencies.Written by Cursor Bugbot for commit ca02a28. This will update automatically on new commits. Configure here.