Malicious code in the purescript NPM installer

Re:Malicious code in the purescript NPM installer by geofft on Sunday July 28, 2019 @05:17PM (#20549887)

How would that have helped things in this case? If we go with the hypothesis of an angry maintainer getting revenge, would they not be just as angry at their project being forked by the community, and just as able to sabotage it via other libraries still in their namespace? (And perhaps more willing, since their original name is still around.) If we go with the hypothesis of a compromised account, people will still be installing the package from the original maintainer's namespace, so they'll still get the malicious code.

And in all likelihood, because the story here is that the maintainer intentionally (though begrudgingly) transferred ownership, they would have intentionally (though begrudgingly) given other people access to the package in their namespace, simply because people value the namespaced name. (If they didn't, and everyone was immediately happy to install anyone/purescript, then namespacing doesn't solve any problems and also creates some!) And the situation would have played out as given.

[ Parent | on HN ]

Re:Malicious code in the purescript NPM installer by delinka on Sunday July 28, 2019 @07:48PM (#20550478)

Why would anyone who owns a namespace be willing to leave a package that's moving to another maintainer within their own namespace? A namespace tends to come with a reputation, and if you give an outsider access to the namespace, the reputation can change without the owner's consent. No, I don't think I'd be allowing @delinka/ExcellentPackage to be maintained by someone else. They can fork it to @fredralphbob/ExcellentPackage and I'll turn off @delinka/ExcellentPackage when I'm done maintaining it. Yep, it'll break dependent installs, but that's the point: get dependents to move to the proper version. I think of a namespace like a domain. If I host a project at project.delinka.engineer, I'm definitely not transferring access to the subdomain to a new maintainer.

Yep, we still have people who would eschew best practice and go against my method above, but that happens everywhere. Just because a solution isn't perfect doesn't mean it's not an improvement.

[ Parent | on HN ]

Re:Malicious code in the purescript NPM installer by geofft on Sunday July 28, 2019 @11:40PM (#20551357)

> Why would anyone who owns a namespace be willing to leave a package that's moving to another maintainer within their own namespace? A namespace tends to come with a reputation, and if you give an outsider access to the namespace, the reputation can change without the owner's consent. No, I don't think....

Good first-principles argument, but in practice, this happens in ecosystems that do have namespaced packages. Off the top of my head:

- Until recently, kennethreitz was a GitHub organization so other people could manage kennethreitz/requests etc.

- Foursquare's Android app is still com.joelapenna.foursquared, which originally was a third-party app that got adopted by Foursquare and turned into their official app. Joe never worked for Foursquare.

- When Linus took a break from Linux development for 4.19, Greg K-H still released it from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... and https://github.com/torvalds/linux .

[ Parent | on HN ]

Re:Malicious code in the purescript NPM installer by yawaramin on Sunday July 28, 2019 @09:18PM (#20550792)

> Yep, it'll break dependent installs, but that's the point: get dependents to move to the proper version.

Probably more realistically, you'd put a note in your @delinka/ExcellentPackage repo readme saying that the package is deprecated and to use @fredralphbob/ExcellentPackage instead going forward, and simply not publish any more new versions. In fact I'm pretty sure npm has a built-in system to warn users of a package that its canonical name has changed.

[ Parent | on HN ]