You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I finally checked properly why I wasn't getting any findings, and it turned out it was beacause I was on zizmor 1.23.1. Its adhoc-packages audit doesn't flag these installs yet, and its the reason analyze --org rust-lang came back empty on my machine, which is why I opened #69 before the org was actually clean.
I've upgraded to 1.30.1 and can see all of them now:
rust-clippy, .github/workflows/remark.yml (npm install remark-cli ...)
chalk, .github/workflows/publish.yml (npm install -g auto-changelog@2.2.1)
rust-bindgen, .github/workflows/bump-version.yml (npm install doctoc)
rust-playground, .github/workflows/ci.yml (gem install bundler)
rust-lang/rust has one too, but it's in the vendored clippy copy under src/tools/clippy.
I've been looking at how to fix these and wanted to run it by you first.
Pinning the versions doesn't help, which surprised me. chalk already pins its one with auto-changelog@2.2.1 and it still gets flagged. The only things that pass are npm ci and bundle install, so it looks like it really wants a lockfile.
rust-playground already has a Gemfile and Gemfile.lock, so there's just the gem install bundler line to remove.
The other three are what I'm unsure about. rust-clippy, rust-bindgen and chalk have no npm setup at all, they just call a node tool in CI, so fixing them means adding a package.json and committing a package-lock.json to each. rust-analyzer does keep one, but node is actually part of what it builds, here it would only be for CI.
In general I agree with introducing lockfiles for npm-based ad hoc packages. If maintainers do not agree with this take, perhaps we could ignore this audit case by case, eventually creating a companion follow-up issue for the maintainers (on the target repo).
In addition, it's important to understand how these ad hoc packages are used : if we are talking about companion CI jobs like linting markdown, etc, it's easier to accept an eventual push-back and just ignore this finding. I did not analyze the workflows you listed, but in a rule of thumb, the closer a workflow is to some critical artifact (e.g. publishing some stuff using ad hoc packages), the greater the incentive to push for these lockfiles (imho).
For ruby, mostly like bundler is bundled (😄) within the Ruby distribution, so it should be safe to remove this line in rust-playground.
For rust-lang/rust, the resolution follows what rust-ciippy decides
A quick update: a fresh scan with the lint enabled only flags rust-clippyand rust-bindgen which are waiting on their PRs, so I'll open the PR enabling it once those two are merged.
Activity
Sandijigs commentedon Sep 11, 2026
I finally checked properly why I wasn't getting any findings, and it turned out it was beacause I was on zizmor 1.23.1. Its adhoc-packages audit doesn't flag these installs yet, and its the reason analyze --org rust-lang came back empty on my machine, which is why I opened #69 before the org was actually clean.
I've upgraded to 1.30.1 and can see all of them now:
rust-clippy, .github/workflows/remark.yml (npm install remark-cli ...)
chalk, .github/workflows/publish.yml (npm install -g auto-changelog@2.2.1)
rust-bindgen, .github/workflows/bump-version.yml (npm install doctoc)
rust-playground, .github/workflows/ci.yml (gem install bundler)
rust-lang/rust has one too, but it's in the vendored clippy copy under src/tools/clippy.
Sandijigs commentedon Sep 11, 2026
I've been looking at how to fix these and wanted to run it by you first.
Pinning the versions doesn't help, which surprised me. chalk already pins its one with auto-changelog@2.2.1 and it still gets flagged. The only things that pass are npm ci and bundle install, so it looks like it really wants a lockfile.
rust-playground already has a Gemfile and Gemfile.lock, so there's just the gem install bundler line to remove.
The other three are what I'm unsure about. rust-clippy, rust-bindgen and chalk have no npm setup at all, they just call a node tool in CI, so fixing them means adding a package.json and committing a package-lock.json to each. rust-analyzer does keep one, but node is actually part of what it builds, here it would only be for CI.
Is that ok to do, or is there a better way?
ubiratansoares commentedon Sep 22, 2026
Hi @Sandijigs , apologies for the late reply.
In general I agree with introducing lockfiles for npm-based ad hoc packages. If maintainers do not agree with this take, perhaps we could ignore this audit case by case, eventually creating a companion follow-up issue for the maintainers (on the target repo).
In addition, it's important to understand how these ad hoc packages are used : if we are talking about companion CI jobs like linting markdown, etc, it's easier to accept an eventual push-back and just ignore this finding. I did not analyze the workflows you listed, but in a rule of thumb, the closer a workflow is to some critical artifact (e.g. publishing some stuff using ad hoc packages), the greater the incentive to push for these lockfiles (imho).
For ruby, mostly like bundler is bundled (😄) within the Ruby distribution, so it should be safe to remove this line in
rust-playground.For
rust-lang/rust, the resolution follows whatrust-ciippydecidesSandijigs commentedon Oct 5, 2026
A quick update: a fresh scan with the lint enabled only flags rust-clippyand rust-bindgen which are waiting on their PRs, so I'll open the PR enabling it once those two are merged.
ubiratansoares commentedon Oct 5, 2026
Thanks @Sandijigs!
Install remark from a lockfile (rust-lang#17820)
Sandijigs commentedon Oct 28, 2026
adhoc-packages now applies to every repository except chalk, which is excused on purpose
so I think this can be closed