`npm audit signatures` does not report how many packages it skipped for want of registry keys
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 70/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, nodejs
Research direction
Look at the audit signatures command implementation, likely in lib/commands/audit-signatures.js or a similar audit module. Find where auditedWithKeysCount is tracked and where the summary output is generated. The change involves adding a skipped count to the output, using the registry resolution data already available. Test by setting up a local registry without keys and verifying the new message appears.
Written by the indexing model from the issue text.
Description
Current behaviour
When a registry does not publish signing keys, audit signatures skips the packages installed
from it. That part is intended — #5479 asked for E400 to be treated like E404 for exactly
this reason, and the summary counts only what was checked, through auditedWithKeysCount.
What the summary does not say is how much was skipped. In a tree where some dependencies resolve
from a registry with keys and some from a registry without, the output and the exit code are
indistinguishable from a tree that was fully verified.
Reproduced on npm 10.9.8 with a local registry that answers 404 on /-/npm/v1/keys:
$ cat package.json
{ "name":"mixed-test","version":"1.0.0",
"dependencies":{ "@nl/nokeys-dep":"1.0.0", "lodash":"4.17.21" } }
$ cat .npmrc
@nl:registry=http://127.0.0.1:8899
$ npm audit signatures
audited 1 package in 0s
1 package has a verified registry signature
$ echo $?
0
@nl/nokeys-dep is in the tree and carries no signature. It is not in the audited count, not
under missing, not under invalid. Nothing in the output indicates it exists.
When nothing can be audited the command already does the right thing:
$ npm audit signatures
npm error found no dependencies to audit that were installed from a supported registry
$ echo $?
1
Why it matters
A pipeline that runs npm audit signatures and branches on the exit code is asking "is this tree
verified". In the mixed case it is told yes, when the honest answer is "the part of it that could
be checked". The configuration where this arises — part of the tree resolving through an internal
mirror, a proxy or a third-party registry that does not publish keys — is a common one, and
arguably the one where the gate matters most.
The tree's total is not printed next to the audited count, so the two cannot be compared without
counting the lockfile separately.
Suggested change
Report the skipped count. Something like:
audited 1 package in 0s
1 package skipped: no signing keys published by http://127.0.0.1:8899
1 package has a verified registry signature
The information is already in hand at that point — the edges walked, the registries resolved and
auditedWithKeysCount — so this is a reporting change rather than a behavioural one. Whether a
skipped package should also affect the exit code is a separate decision, and a flag along the
lines of --require-signatures would leave the current default alone.
I am not suggesting the skip itself should change.
- Dominant language
- JavaScript
- Stars
- 10.2k
- Forks
- 4.8k
- Avg merge
- 3d 21h
- Merged PRs (30d)
- 12
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from npm/cli
-
[BUG] v12.2.0 shipped a stale bundled lockfile after in-range security fixes were already publishedPossibly taken @reggi claimed this 5 days ago. OpenPriority 1
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
npm/cli#10062 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
-
create node pr: Node.js 20 deprecation & `DEP0040` warnings loggedPossibly taken @lazerg claimed this 17 days ago. OpenPriority 1
Difficulty 1/5 Under an hour Newbie friendliness 80/100
Maintainers usually reply within 1 day
-
Engineering Priority 2
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
[BUG] E401 error message does not use the configured registryPossibly taken @toufiq-dev claimed this 16 days ago. OpenBug Priority 3
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
[DOCS] Clarify whether `os`, `cpu`, and `libc` accept a string or must be an arrayPossibly taken @SatvikMishra08 claimed this 14 days ago. OpenDocumentation Priority 2
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 71/100
yjh051108/dsh-routing-suite#227 ·
-
needs-triage release-watch
Difficulty 1/5 Under an hour Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
dusk-network/exu#17 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
jspreadsheet/ce#1809 ·
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 91/100
githubnext/gh-aw-workshop#4458 ·
Maintainers usually reply within 1 day