Malicious code in the purescript NPM installer

[hombre_fatal]

Another reminder of how annoying it is for a package system to have unqualified package names.

Having to ask someone to gift a `purescript` package shouldn't even be a thing. It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`.

This is something Elm and many others got right. https://package.elm-lang.org/ It's just infinitely, obviously better.

You see all sorts of problems because of this, like people "giving packages away" when they quit. Or buying package names. Or coming up with annoying name hacks because the obvious, best name is simply taken. Or people thinking/guessing that `npm install mysql` is the correct/best/canonical package because it's the simplest name, and anyone who publishes a better library has to name it mysql2 or better-mysql, etc. These just shouldn't even be things.

[munificent]

> It's just infinitely, obviously better.

Whenever a large number of skilled people do something for which an alternative is "infinitely, obviously better", there's a good chance that there is more going on than you know.

RubyGems used to be namespaced this way and moved away from it. They didn't do so lightly.

The problem is that ownership, and even names of owners change all the time. In the very very large majority of cases, this change of ownership is an implementation detail that doesn't need to impact package consumers. If you enshrine the owner's name in the package, it means any change of ownership is effectively a breaking change to the package. When you have very large transitive dependency graphs, the result is constant, pointless churn.

[geofft]

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.

[trabant00]

Imo your solution is just a band aid. The real solution is having a distribution of packages which are maintained and suppervised by a group of people. Like the linux distribution maintainers or the group that develops the language.

Community contribuited packages should be declared "install at own risk" like in archlinux aur.

All this is already solved. But people want to reinvent the wheel and ride the user generated content train.

[neilv]

Java got that part right in the 1990s, when it was the cool Web-savvy language. At the time, I especially liked how they piggybacked onto the existing DNS domain name control, avoiding having to create a new centralized registry to keep names unique. (Of course, more could be done beyond that, today.)

[naniwaduni]

This is not a package namespacing issue. This is not a technical issue. It is mechanically no more difficult to change from "@shinn/purescript" to "@whatever/purescript" than it is to change from "purescript" to "purescript-whatever", except that in the common cases (where no disputed community moves have occurred without a corresponding name change) everyone has to include an author. The author can still "give away" or sell package names; a lot the value is not in holding the name, but having the existing installed base and mindshare.

These are the social issues associated with a hostile fork.

[timothycrosley]

I don't actually feel like this solves anything, but instead just adds one more avenue for name hijacking. Now instead of trying to register an angular package first, I'll try to register a google namespace, or similar. If google is taken, I'll make an official_google, or g00gle etc.

[McGlockenshire]

Even PHP gets this right. It's not hard. It makes me wonder why npm hasn't already moved to namespaced package names.

[littlestymaar]

> It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`.

And how is a user supposed to make the difference between @legit_dev/package_name and something like @nlegit_dev/package ?

Namespacing makes name-squatting way easier, not harder.

[lonelappde]

There's nothing preventing whatever_purescript. Even if you have namespacing, anyone who owns a spot in it can sell or rent their spot to a malicious actor.

[dane-pgp]

Fortunately it seems to be something that Entropic gets right:

https://github.com/entropic-dev/entropic

If it ends up supporting PGP signatures for packages (ideally created by developers using air-gapped machines) then so much the better:

https://github.com/entropic-dev/entropic/issues/86#issuecomm...

[nullwasamistake]

Java got this right with reverse domain names over a decade ago. To use a namespace you have to own the URL. Simple and effective abuse resistant package naming.

[svnpenn]

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

[SCLeo]

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.

[aur09]

Wow—and spread into 11 files to facilitate CI, linting, etc—and with 1kb worth of error checking. That is nuts!

[jasonhansel]

...wow. I literally did not believe that until I clicked the link. JavaScript has gone too far.

[TeMPOraL]

And this one-liner library even has a dependency (!) used by the surrounding error-checking code.

[lenkite]

Don't know whether to laugh or cry at this. Truth is stranger than fiction in the land of JavaScript. Could any developer 20 years ago predict this is what software engineering on the Web would devolve to ?

[ww520]

But it's great for resume and portfolio.

[na85]

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.

[Benjammer]

I always think of this article when these things come up:

https://hackernoon.com/im-harvesting-credit-card-numbers-and...

[z3t4]

Before "tree shaking" I stored all npm modules in SCM and reviwed all updates as I had to commit after "npm update". I also put ton of files in .ignore as 90% of files in some packages are not required. I also used to include npm modules in distribution/deployment. So my request to npm is to add an option in the main package.json to disable tree shaking.

[robocat]

I wish there was a way to "bless" packages when they were reviewed.

I want a network of trust, such that a Google reviewed package is worth 10 points, a package fuzzed by foobar is worth 2 points, something skimmed by a dependant user is worth 1 point etc.

I can then chose a compromise between a highly rated/reviewed dependencies and functionality/risk/cost-to-review.

My own blessing of a package I have reviewed might become a very small signal in a web of trust.

[kreetx]

I evaluated wordpress plugins this way, a good way to check if something strange had crept in.

By the ignored files do you mean non-code?

[nightkoder]

I have been installing purescript using Nix from https://github.com/justinwoo/easy-purescript-nix for a while now. It works quite well and I get to avoid npm.

[Shoue]

Purescript (purs) is in unstable now as well

[a-dub]

I wouldn't use the words "malicious" or "exploit" wrt this... It's more like, I dunno, trolling on planet JavaScript? I feel like there should be a big Twitter fight about it...

[nameiscubanpete]

That was my first thought. But then I realized some guy basically broke something so his stuff would work and someone else's wouldn't. He didn't destroy files, but that was malicious as hell.

[Thorrez]

shinnn is claiming his account was hacked, and the hacker added the code. Generally if a hacker hacks someone's npm account and adds harmful code, that would be considered malicious and an exploit.

[runeks]

The work “exploit” is used several times but none of the code seems to exploit anything. Also, “malicious code” usually has a different meaning than something that intentionally makes the program crash during the installation process.

[samirm]

Agreed about this not being an exploit, but this is definitely malicious code.

[rjmunro]

I feel like this is only part of a wider attack - like by causing this not to download, it meant that users do some other action which opens them up to the real attack.

[bsamuels]

I wonder how bad will this cred-stuffing package authors problem will get before npm/other package managers flat out require 2FA for maintainers

[blackoil]

What JS needs a standard library(s). Developed and manintained by MS/Google or preferably a foundation. No reason every library have a 10 level deep dependencies.

[s_Hogg]

High-velocity ecosystems like this make it way too easy to optimise your code for getting pats on the head. It's good that people are pointing out things like this (relatively speaking) not long after the fact, and that a lot of people on here are annoyed about it. The fix is cultural as much as any 2FA implementation.

[quickthrower2]

Part of the problem is the bounty for attacking NPM packages is high. You get a high profile exploit and lots of people talking about it, or you can even get some of your evil JS code running on thousands of sites on the back end or the front end.

Compounded by the fact there is no decent base class library for JS like you'd get for .NET [0]. Want to do anything you could do by default with .NET BCL? Like open a url, save a file (with nice api) or parse some XML?

Then npm i ... it is. And hope it doesn't pull in an exploit.

As a mitigation I recommend people consider writing their own code (NIH) for simple stuff not npm i all the things.

[0] I'm comparing to .NET but same could be said of Java/Python/Ruby etc.

[SanchoPanda]

This is not the first time this year we see an npm issue, and it could have been much worse than this. All package managers in general create risks, but how the community etiquette evolves around package managers is just as important. Something is wrong with the latter here.

[ruuda]

One of the things I like about Purescript is that you can use it without needing any javascript package manager, and without running any javascript outside of a browser. Nix works well for installing the Purescript compiler as well as psc-package. https://nixos.org/nixos/packages.html#purescript

[dmix]

This was first posted 16 days ago https://news.ycombinator.com/from?site=garrood.me

[gitgud]

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 would greatly reduce code reuse and increase redundancy and complexity of packages (every package may have to roll there own X, or compile their package dependencies into bundled JS with no dependencies).

I think the problem is simply; it's a low friction dependency management solution -> which made it so popular -> which is making it a target for malicious actors.

[ricardobeat]

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.

[umanwizard]

> that friction will drastically slow down the ecosystem

This is a feature.

[austincheney]

Uniqueness and trust of package naming is easily solved: use a URI. It doesn't even have to resolve. URI is a naming convention that invokes both uniqueness and universality.

[weq]

So what you are saying, is all the code i see on blogs, demoing that cool little JS thingy, is actually just demo code, not prod ready. To get prod ready, u need to break the NPM dep, and vet everything on your own. So your telling me npm run serve isnt good enough for prod either?!

Lies, more lies and broken promises!

[sieabahlpark]

Well I guess it's good I didn't start using this after an article I saw yesterday about it.