Skip to content

[Snyk] Security upgrade bip85 from 0.0.3 to 1.0.0 #28

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
revan-zhang wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[Snyk] Security upgrade bip85 from 0.0.3 to 1.0.0 #28

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion libs/combined/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@
"bech32": "1.1.4",
"bip38": "2.0.2",
"bip38grs": "git://github.com/Groestlcoin/bip38grs.git#091975b01679b74dc0a4136bb743fe17791b0151",
"bip85": "0.0.3",
"bip85": "1.0.0",
Copy link
Copy Markdown

@devin-ai-integration devin-ai-integration Bot Mar 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 package-lock.json not updated to match bip85 version bump to 1.0.0

The package.json bumps bip85 from 0.0.3 to 1.0.0, but libs/combined/package-lock.json still pins bip85 at version 0.0.3 (see libs/combined/package-lock.json entries under both dependencies and packages). This means npm ci (which respects the lockfile) will still install 0.0.3, making the version bump ineffective. Running npm install would update the lockfile, but the lockfile should be committed as part of this PR to ensure deterministic builds.

Prompt for agents 
Run `npm install` (or `npm update bip85`) inside the `libs/combined/` directory to regenerate `libs/combined/package-lock.json` with bip85 version 1.0.0, then commit the updated lockfile alongside the package.json change. Also verify that the bip85 1.0.0 API is compatible with the usage in src/js/index.js (specifically BIP85.fromBase58, deriveBIP39, deriveWIF, deriveXPRV, deriveHex methods), since this is a major version bump that may include breaking changes.
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Copy link
Copy Markdown

@cursor cursor Bot Mar 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lock file not updated, will break npm ci

High Severity

The package.json now specifies bip85 version 1.0.0, but libs/combined/package-lock.json still references version 0.0.3 throughout (both in the packages and dependencies sections). This mismatch will cause npm ci to fail, since it requires the lock file to be in sync with package.json. If npm install is used instead, it may update the lock file — but only if version 1.0.0 actually exists on npm.

Fix in Cursor Fix in Web

Copy link
Copy Markdown

@cursor cursor Bot Mar 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Major version bump may break bip85 API usage

High Severity

Upgrading bip85 from 0.0.3 to 1.0.0 is a semver-major bump, and the Snyk metadata itself flags "isBreakingChange":true. The codebase calls specific APIs — BIP85.fromBase58(), .deriveBIP39(language, length, index).toMnemonic(), .deriveWIF(index).toWIF(), .deriveXPRV(index).toXPRV(), and .deriveHex(bytes, index).toEntropy() in src/js/index.js — whose signatures or return types may have changed in v1.0.0, silently producing incorrect cryptographic output or runtime errors.

Fix in Cursor Fix in Web

"bitcoinjs-lib": "git://github.com/iancoleman/bitcoinjs-lib.git#v3.3.2_16bit",
"bs58": "^4.0.1",
"buffer": "^5.4.3",
Expand Down
Loading