[RRFC] Verify publisher identity for reused repository URLs

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

No implementation files, tests, or entry points are identified in the issue; begin by reviewing the desired publisher cross-check, provenance flow, notifications, dispute handling, and fork designation. Done would require an agreed design and an implementation plan for these publishing-safety behaviors, since the references are listed as n/a.