Created recursive script for *nix systems#23
Created recursive script for *nix systems#23jamsajones wants to merge 17 commits intotheNetworkChuck:mainfrom
Conversation
This script is a copy of the check.sh file to recursively find and scan all JS projects.
…sh to avoid false positives and check all versions in dependency tree
…ency tree and parent packages
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>
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>
…ack" This reverts commit a3cdcbf.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
jamsajones
changed the title
Shows a live counter while find is scanning so the user knows the script is still running on large directory trees. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Extends the dep tree scan (from PR theNetworkChuck#6's npm list --all) to yarn, pnpm, and bun across all four scripts: check.sh, check.ps1, check-revursive.sh, and check-recursive.ps1. - npm: npm list axios --all - yarn: yarn why axios - pnpm: pnpm list axios --depth=Infinity - bun: bun pm ls --all Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove sort -u pipe which buffered all output until find completed. Deduplicate in-loop with an associative array instead, so the counter updates in real time as projects are found. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This reverts commit d1e1afc.
Show a spinning animation while find runs in the background so the user knows the script is working. Default scan root changed from $HOME to current working directory. Bash 3.2 compatible (no associative arrays). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Skip .bun, .yarn, .pnpm, .pnpm-store, .npm, .cache, Cache, and Caches directories to avoid false positives from cached package metadata. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Document the recursive detection script usage and note that it scans the current directory by default. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
I have a concern about how It looks like the scripts decode it by running Could we test what happens if a repository contains a malicious or non-standard If there is any ambiguity here, it might be safer to either:
Just want to make sure we’re not implicitly trusting input that comes from repos. |
|
@DenisLantero thanks for the feedback.
Happy to work on this more and solve the issue but I am no bun expert and so I don't fully understand the issue that you are addressing here. Will take me some time to research and fix without more info (2:35a here on the west coast of the us). I would also be happy to merge anything you think needs to change into this repo with a PR. |
|
FWIW, this was a great effort by @theNetworkChuck to help scan for this very quickly. THANKS @theNetworkChuck! Considering that I am not a security professional (although we all have to wear that hat and try) and I don't know what the long term intent is of @theNetworkChuck for this project, if this solution only works for me so be it... no ego here. So, if you have a better solution please take over my work (pull my code into your own version of this) or replace it and I will close the PR. The important thing is that the community has a safe, reliable, and fast answer to know if they were impacted, and that is all that matters to me. ¯\_(ツ)_/¯ |
Thanks, that makes sense, I think I can clarify my concern better. I’m not saying this is definitely an exploitable issue, just something that might be worth double checking. The scenario I have in mind is this:
Even if bun intends to treat I don’t have proof that this leads to code execution or anything like that , just pointing out that we are invoking a CLI on content that might be malicious. Since this is a local script, a simple "fix" could be something like adding a warning "If you have untrusted repositories on your machine, you may want to skip scanning bun.lockb files", or something along these lines, a simple prompt to the user asking if he wants do disable checking |
You did a great job, I prefer your approach to this script since it is more complete and it has a broader scope. The issue I pointed out is only a remote possibility, since users might think "Let me run this on my root to check my whole machine" (like I did) and might have unsafe code cloned, a simple way to turn the bun check on / off might be a good feature (even a y/n prompt). If you can implement this it would be great, otherwise I'd be happy to open a PR if needed! |
5 participants
Summary
Implemented a recursive version of the script to it will look through my home directory for all projects that have a
package.jsonfile. It then uses @cristianchies dependency scanning tree solution (#6 ) to find if any deps of that project contain axios. It also incorporates @Bassonrichard's PR (#8 )to ensure that all projects are found regardless of the package manager (attribution was maintained). PR #1 was pulled in for good measure.