pnpm audit signatures: a 'terminated' reason is a network error, not tampering

pnpm audit signatures can break a CI gate with a terrifying “Someone might have tampered with this package” message, when the real cause was a transient HTTP error. The giveaway is the reason column: terminated is the message of an aborted fetch, not a cryptographic verdict.

What I Learned

The error looks like this:

1 package has an invalid registry signature:
┌───────────────────────┬─────────────────────────────┬────────────┐
│ @firebase/auth@1.13.3 │ https://registry.npmjs.org/ │ terminated │
└───────────────────────┴─────────────────────────────┴────────────┘
Someone might have tampered with this package since it was published on the registry!

A re-run passes: 1494 packages have verified registry signatures.

To verify a package, pnpm fetches its registry packument and reads dist.signatures. If that request throws (timeout, connection reset, abort), the error is caught and the package is recorded as invalid with reason: err.message:

// pnpm — deps/compliance/commands/lib/audit/signatures.js (paraphrased)
try {
  const packument = await getPackument(pkg, getAuthHeader, opts, cache);
} catch (err) {
  result.invalid.push({
    ...pkg,
    reason: isNativeError(err) ? err.message : String(err),
  });
}

Node’s fetch (undici) aborts with message: "terminated", so one failed packument fetch among thousands gets rendered as “invalid registry signature / possible tampering.” A signature either verifies or it doesn’t. There is no “terminated” state in ECDSA verification.

To confirm it’s transient, re-run pnpm audit signatures. A network blip won’t reproduce. Only if the same package fails again should you investigate the actual signature. Don’t exclude the package from the trust policy or weaken the gate on a single terminated.

References

• About ECDSA registry signatures (npm Docs): how dist.signatures and the /-/npm/v1/keys endpoint work
• pnpm: audit signatures implementation