[RRFC] Verify publisher identity for reused repository URLs

[aqeelat]

Motivation ("The Why")

Publishing to npm today allows anyone to set the homepage and repository fields in their package metadata without any verification. This gap makes it trivial for a malicious actor to impersonate popular packages by reusing their metadata, tricking users into installing modified or harmful code under a familiar name.

Example

Consider these two packages:

• fs-extra (the legitimate package):
  https://npmjs.org/package/fs-extra
  repository: https://github.com/jprichardson/node-fs-extra
  latest version: 11.3.0
• fs-extra2 (imposter):
  https://npmjs.com/package/fs-extra2
  repository: https://github.com/jprichardson/node-fs-extra
  latest version: 1.0.1

At a glance, the metadata matches exactly—but the version (1.0.1) in the imposter does not correspond to any tagged release in the real fs-extra GitHub repo. A user who installs fs-extra2 may assume they’re getting the genuine library, whereas they’re actually pulling unverified code.

How

Current Behaviour

• No metadata verification
  npm does not check that the maintainer/publisher of a package matches the owner of the homepage or repository URLs specified in package.json.
• Unilateral package creation
  Anyone can publish a new package whose metadata duplicates that of an existing package (aside from the package name).
• No notification to original maintainers
  The legitimate publisher has no way of knowing when someone else reuses their repo URL or homepage in a different package.

Desired Behaviour

1. Metadata‑to‑publisher cross‑check
   When publishing a package whose repository or homepage URL exactly matches that of a previously published package:
   • Verify that the npm publisher account matches the GitHub (or other VCS) repo owner.
2. Provenance verification flow
   If the publisher accounts don’t match:
   • Prompt the uploader to prove they have rights to those URLs (for example via GitHub’s provenance or an ownership token).
3. Maintain transparency and safety
   • Send an automated email to the original publisher(s) of the URL in question, informing them that another package is reusing their metadata.
   • Allow the original publisher to confirm or dispute:
     • If confirmed: proceed with the publish.
     • If disputed or unconfirmed within a grace period: either block the publish or add a clear “⚠️ Unverified repository URL” label on the package’s npm page.
4. Optional “fork” designation
   • In cases where the author legitimately forks a project, allow a “fork” checkbox or CLI flag that marks the package as a fork of the original.

References

• n/a