feat: extend lockfile checks to yarn, pnpm, bun, and deno#8
Open
Bassonrichard wants to merge 3 commits intotheNetworkChuck:mainfrom
Open
feat: extend lockfile checks to yarn, pnpm, bun, and deno#8Bassonrichard wants to merge 3 commits intotheNetworkChuck:mainfrom
Bassonrichard wants to merge 3 commits intotheNetworkChuck:mainfrom
Conversation
Scan yarn.lock, pnpm-lock.yaml, and deno.lock alongside package-lock.json. For bun.lockb (binary format), decode via `bun bun.lockb` when available and warn if bun is not installed rather than silently skipping. Also extend git history forensic scan to cover all lockfile types. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previously, the version regex (1.14.1|0.30.4) was matched across the entire lockfile, flagging any package that happened to share those version numbers. For example, dashdash@1.14.1 — a completely unrelated argument parsing library — would trigger a false AFFECTED result. Lockfile checks are now scoped to axios entries only: - package-lock.json: searches within the "node_modules/axios" block - yarn.lock / bun (decoded): uses awk to find blocks whose header starts with "axios@" before checking the resolved version field - pnpm-lock.yaml: matches "/axios@VERSION:" key format explicitly - deno.lock: matches "axios@VERSION" JSON key format explicitly Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
NOOO NOT THE AI |
|
============================================ Preventive steps:
|
In check.ps1, $lockHit was not reset before the package-lock.json block, meaning a truthy value from a prior run could carry over and trigger a false positive. Fixed by initialising $lockHit = $null at the top of each block. Also corrected the LineNumber offset: Select-String returns 1-based line numbers but PowerShell arrays are 0-indexed, so the block slice now uses ($axiosIdx - 1) to avoid skipping the matched line. Bumped the slice window from +3 to +4 lines to match the -A 5 depth used in check.sh. In check.sh, bumped grep -A 3 to -A 5 so the version field is captured in npm lockfile v1/v2 where it may sit deeper in the block. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Author
|
I made a change to now give package specific tips @Coding4Hours , it also fixes some false positives just checking the version i.e: |
|
nice @Bassonrichard |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Extends lockfile scanning to cover yarn.lock, pnpm-lock.yaml, and deno.lock in addition to package-lock.json
Adds correct handling for bun.lockb, which is a binary file and cannot be grepped directly
Why additional lockfile checks?
The previous script only checked
package-lock.json(npm) on Windows, and fell through toyarn.lockonly as an elif on Linux/macOS - meaning projects usingpnpmorDenowould get a false "SKIP: No lockfile found" result even if a lockfile existed. Developers who install the compromised axios version via any package manager are equally at risk, so all common lockfile formats should be scanned.Why bun.lockb needs special handling
bun.lockbuses a binary serialization format (JavaScriptCore's binary AST). Running grep against it directly is unreliable - version strings like 1.14.1 may not appear as plain ASCII in the binary encoding, meaning a compromised version could be present and go undetected. (This happened to me)The fix decodes the lockfile first using bun
bun.lockb, which outputs a human-readable yarn/npm-style text representation, and then greps that output. If bun is not installed, the script now emits an explicit warning rather than silently skipping preventing a false negative.