[Klathmon]

As others have said, npm has ways of marking a package version as deprecated and npm also has scoped packages.

So if you wanted to stop maintaining your very own `right_pad`, you could mark it as deprecated so devs installing it get a warning in the CLI, and I could then publish my own `@klathmon/right_pad` and if you want you could endorse it in your readme if you wanted.

[danShumway]

The problem is that if I mark my original right_pad as deprecated and then point to yours, we're in the exact same situation -- people who blindly follow the instructions on my repo will still download your compromised version and have their credit cards stolen.

If I mark my package as deprecated and I don't point to yours, then malicious actors flood with copycat namespaces, and you have @klathmon/right_pad, @danshumway/right_pad, @linus/right_pad, and even the occasional phished @k1athmon/right_pad. Would that extra confusion be enough to trigger an audit for a company that wasn't planning to audit the original dependency anyway? Would an overworked engineer have the presence of mind to double check that their version has the right prefix?

There are, I'm sure, people who think it's OK to upgrade a package without worrying about the security implications, but not OK to switch to another package when the original is marked as deprecated. But I don't know that those people are in the majority. Certainly, anyone who's not already using a lock file and freezing their dependencies is probably not gonna think too hard about this.

(Somewhat to my shame) I can think of several instances where I personally have found a repo marked as deprecated on Github, went to the repo that it pointed me at, and started using it without even checking to see who the new author was.

Maybe I'm atypical with that behavior?

[perpetualcrayon]

I don't think anyone would expect different behavior out of end users. But the "instant gratification" a malicious actor is seeking by asking to "maintain a package" will be delayed substantially. In fact, if you are straight up with folks telling them that you don't personally know who is now maintaining the fork, folks who do decide to trust them will know to proceed with caution and will probably watch the PRs on the repo for a period of time. So, technically not only are we delaying instant gratification of being given access to probably millions of "hits", we're forcing the malicious actor to actually maintain the package and gain the trust of the community independently before they can wreak havoc.

Then over time if it's an important enough package there will probably be discussions or blog posts about the new maintainer and what a "fantastic" or "terrible" job they're now doing.