Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious code in the purescript NPM installer

harry.garrood.me

Post reply on HN
Print view View original

91–100 of 279 posts

Re: Malicious code in the purescript NPM installer

#91

Post by na85 »

svnpenn wrote: post #80

The real issue the Balkanization of JavaScript programs. The `rate-map` package is essentially one line of code: start + val * (end - start); https://github.com/shinnn/rate-map/blob/90c234c9/index.mjs#L...

It's an ecosystem full of reinventing the wheel. The most popular library, lodash, includes a reimplementation of a foreach loop for Pete's sake, for reasons passing understanding since it's part of the ecma spec.

JavaScript is just amateur hour, and these things are going to keep happening. It's pathological.

Re: Malicious code in the purescript NPM installer

#93

Post by yawaramin »

delinka wrote: post #74
geofft wrote: post #36

Earlier quoted context omitted.

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 b…

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/Excelle…

> 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.

Re: Malicious code in the purescript NPM installer

#94

Post by yawaramin »

Fellshard wrote: post #65
buzzerbetrayed wrote: post #63

Earlier quoted context omitted.

So by looking at a tiny fraction of the 1 million+ npm libraries, and articles by a few dozen people on the internet, you are able to conclude that the > vast majority of JS developers don't seem to be aware of the rest of the software universe Forgive me if I dismiss this as business-as-usual JS bashing

There is a difference between arbitrary bashing and giving concrete points of concern. I would hope such criticism would not be dismissed out of hand.

What concrete points of concern? I don't see any...?

Re: Malicious code in the purescript NPM installer

#95

Post by yawaramin »

braythwayt wrote: post #55
dcbadacd wrote: post #50

Earlier quoted context omitted.

The refund for the amount you paid for the library is on its way. Once again I'm reminded about that sentence someone once said. With random open-source libraries you're dealing with something someone else put out there just because they wanted to, having any kinds of expectations that someone will or won't do something is seriously short-sighted and even pretentious. Do you go around running random .exe-s you find f…

You are not a lawyer, because if you were, you would be aware that there is case law establishing that just because you don't charge for it, doesn't mean you aren't providing an implied warranty and aren't taking implied liability. There is absolutely zero chance that you can put malware into an open source project, give it away, and then when sued, stand up and say, "It was free, what do people expect?" You can call…

> just because you don't charge for it, doesn't mean you aren't providing an implied warranty and aren't taking implied liability.

Open source software is almost always distributed with a license that explicitly disavows any such warranty or liability. This is pretty widely understood...

Re: Malicious code in the purescript NPM installer

#96

Post by hnbroseph »

krainboltgreene wrote: post #66
hedora wrote: post #54

Earlier quoted context omitted.

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

> but those 18K do a lot more than NPM This is so hilariously wrong it's actually shocking it was written?

why is it "so hilariously wrong"?

Re: Malicious code in the purescript NPM installer

#97

Post by hnbroseph »

hedora wrote: post #54
krainboltgreene wrote: post #45

Earlier quoted context omitted.

Please list the group of people you trust to manage 1,037,274 packages.

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

> I trust these people

why?

Re: Malicious code in the purescript NPM installer

#98

Post by ricardobeat »

SCLeo wrote: post #81
svnpenn wrote: post #80

The real issue the Balkanization of JavaScript programs. The `rate-map` package is essentially one line of code: start + val * (end - start); https://github.com/shinnn/rate-map/blob/90c234c9/index.mjs#L...

I honestly don't understand why people use packages like this. If I need this functionality, I will simply write my own. Plus, I will never able to find this specific package. I guess PureScript uses this because its author is also the author of rate-map.

I’ll give you one: it’s code already written and tested by > 1 person, edge cases already figured out. Saves you time. The gains are small but quickly add up.

This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks.

Re: Malicious code in the purescript NPM installer

#99

Post by hnbroseph »

buzzerbetrayed wrote: post #63
Fellshard wrote: post #44

Earlier quoted context omitted.

Primarily, I end up basing this off of the types of libraries being developed for Javascript, and what kinds of articles and thought leaders JS developers tout as innovative.

So by looking at a tiny fraction of the 1 million+ npm libraries, and articles by a few dozen people on the internet, you are able to conclude that the > vast majority of JS developers don't seem to be aware of the rest of the software universe Forgive me if I dismiss this as business-as-usual JS bashing

sure, it's just sampling.

Re: Malicious code in the purescript NPM installer

#100

Post by ricardobeat »

gitgud wrote: post #86

NPM gets a lot of hate for it's dependency managemnet, but I'm not sure what a solution would be to this problem. - They can't currate packages, or else that friction will drastically slow down the ecosystem (1000's of packages get published everyday). - They can't remove/disable packages (most of the time) , or dependencies will no longer be strictly immutable. - They can't disable sub-dependencies, or else this wou…

After 10 years of nodejs I can honestly say I wouldn’t mind the friction. NPM is a wasteland of abandoned packages and reinventing the wheel. They never solved discovery so you have 500x implementations of the exact same thing. Around 2015 we passed the point where looking for the “right” package takes longer than writing your own.
Post reply on HN