[Snyk] Security upgrade near-api-js from 2.1.4 to 4.0.0#10288
[Snyk] Security upgrade near-api-js from 2.1.4 to 4.0.0#10288revan-zhang wants to merge 8 commits intoxfrom
Conversation
The following vulnerabilities are fixed with an upgrade: - https://snyk.io/vuln/SNYK-JS-BNJS-15274301
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
| "js-conflux-sdk": "^2.1.12", | ||
| "jsrsasign": "^10.8.6", | ||
| "near-api-js": "^2.1.4", | ||
| "near-api-js": "^4.0.0", |
There was a problem hiding this comment.
🔴 Major version bump of near-api-js (v2→v4) breaks all consuming code due to incompatible API changes
Upgrading near-api-js from ^2.1.4 to ^4.0.0 introduces multiple breaking API changes, but none of the consuming code was updated to match.
Root Cause and Detailed Breakdown
1. utils.serialize.deserialize 3-argument API removed (borsh v0.7→v1.0)
near-api-js v2 depends on borsh ^0.7.0 which exposes deserialize(schema, class, buffer). near-api-js v4 depends on borsh 1.0.0 which changed to deserialize(schema, buffer) returning a plain object. The code at packages/core/src/chains/near/CoreChainSoftware.ts:80-84 and packages/kit-bg/src/vaults/impls/near/utils.ts:85-89 both call:
utils.serialize.deserialize(
transactions.SCHEMA,
transactions.Transaction,
buffer,
);This 3-argument form will fail at runtime with v4.
2. transactions.SCHEMA format completely changed
In v2, SCHEMA was a Map compatible with borsh v0.7. In v4, SCHEMA is a plain object with struct/enum definitions for borsh v1.0. Even if the deserialize call were fixed, passing the old-style schema would produce incorrect results.
3. SignedTransaction/Signature constructor changes
The code at packages/core/src/chains/near/CoreChainSoftware.ts:114-120 constructs transactions.SignedTransaction and transactions.Signature — the v4 constructors use Assignable with a different initialization pattern.
4. Import path near-api-js/lib/transaction may be removed
Both packages/core/src/chains/near/CoreChainSoftware.ts:31-33 and packages/kit-bg/src/vaults/impls/near/utils.ts:8,13 import from near-api-js/lib/transaction — a deep internal path that may not exist in v4's restructured package layout.
5. bn.js removed as a dependency
packages/kit-bg/src/vaults/impls/near/utils.ts:2 imports BN from 'bn.js' which was a transitive dependency of near-api-js v2 but is no longer a dependency of v4 (replaced by @noble/curves).
Impact: Once the yarn.lock is regenerated (as the PR warns is needed), all NEAR chain operations — transaction building, signing, deserialization, and broadcasting — will break at runtime, making the NEAR wallet completely non-functional.
Prompt for agents
The near-api-js upgrade from v2 to v4 is a breaking change that requires updating all consuming code. The files that need changes are:
1. packages/core/src/chains/near/CoreChainSoftware.ts:
- Line 5: The import `{ transactions, utils }` from 'near-api-js' needs to be verified against v4 exports.
- Lines 30-33: The import from 'near-api-js/lib/transaction' needs to be changed to use the new package structure (likely import directly from 'near-api-js' or '@near-js/transactions').
- Lines 80-84: The `utils.serialize.deserialize(transactions.SCHEMA, transactions.Transaction, buffer)` call must be updated to use the new borsh v1.0 API. In v4, use `transactions.Transaction.decode(buffer)` or `decodeTransaction(buffer)` from '@near-js/transactions'.
- Lines 114-120: The `new transactions.SignedTransaction({transaction, signature: new transactions.Signature(...)})` construction needs to be verified against the v4 Assignable-based constructors.
2. packages/kit-bg/src/vaults/impls/near/utils.ts:
- Line 7-8: Imports from 'near-api-js' and 'near-api-js/lib/transaction' need updating.
- Lines 85-89: Same `utils.serialize.deserialize` 3-argument call needs updating to use `Transaction.decode(buffer)` or the new deserialization API.
- Line 2: Verify that 'bn.js' is still available as it was removed as a transitive dependency of near-api-js v4.
Alternatively, if the goal is just to fix the bn.js vulnerability, consider whether a more targeted approach (e.g., using yarn resolutions to override the bn.js version) would be safer than a major version bump.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
Snyk has created this PR to fix 1 vulnerabilities in the yarn dependencies of this project.
Snyk changed the following file(s):
packages/core/package.jsonNote for zero-installs users
If you are using the Yarn feature zero-installs that was introduced in Yarn V2, note that this PR does not update the
.yarn/cache/directory meaning this code cannot be pulled and immediately developed on as one would expect for a zero-install project - you will need to runyarnto update the contents of the./yarn/cachedirectory.If you are not using zero-install you can ignore this as your flow should likely be unchanged.
Vulnerabilities that will be fixed with an upgrade:
SNYK-JS-BNJS-15274301
Important
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic
Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.