Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

`npm audit signatures` does not report how many packages it skipped for want of registry keys

Open Beginner friendly
#10,018 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@greenlincoln05 is already working on this.

Since Sep 27, 2026.

  • #10048 by @greenlincoln05 — open

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
Domain
cli, security, tooling

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

Priority 3
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

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from npm/cli

All issues in npm/cli

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.