Malicious code in the purescript NPM installer • Hacker News Board

Re: Malicious code in the purescript NPM installer

#41

Post by kreetx » Sun, Jul 28, 2019, 9:26 PM UTC

z3t4 wrote: post #16

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.

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?

Re: Malicious code in the purescript NPM installer

#42

Post by aidenn0 » Sun, Jul 28, 2019, 9:27 PM UTC

luckylion wrote: post #26

johnchristopher wrote: post #11

Earlier quoted context omitted.

> If I later discover that the crash was put there deliberately, I am going to call that malice, and malice that has directly impacted a functioning business and its customers. Hey, it's open source party ! Where is your patch ? /s edit: oh, bummer. Not really open source. Still: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, etc. How are we supposed…

You touch on an interesting point there if the typical disclaimer is included: does that actually protect against willfully damaging code? It's certainly (and reasonably so) very hard to hold a developer accountable for a bug in an open source library they published. But what if they put rm -rf / in the installer with the intent to delete the files of anybody running it? Does "you should've looked" really work there,…

Obviously everything depends on what court has jurisdiction, but aside from the fact that such disclaimers already have little weight, even signed waivers will not protect you from malice or neglect in many places.

Re: Malicious code in the purescript NPM installer

#43

Post by orblivion » Sun, Jul 28, 2019, 9:33 PM UTC

ga-vu wrote: post #3

Not actually malicious. It doesn't steal user data, drop malware, or damage a computer. Just crashes the library. Looks like another developer-developer slap fight.

While people give reasonable counter-arguments here to your point, it gets me thinking - I wonder if we could find a truly benign form of "malicious code" that "good guys" could use to find attack vectors before the "bad guys" do.

Perhaps there could be a website set up to get pinged by "malicious" installers? Perhaps it displays stats of some sort? It could turn into a friendly game.

Re: Malicious code in the purescript NPM installer

#44

Post by Fellshard » Sun, Jul 28, 2019, 9:41 PM UTC

allover wrote: post #33

Fellshard wrote: post #20

Earlier quoted context omitted.

Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe, and so seem to reinvent the wheel, rediscover the worst of software's history, and discard the most useful of software findings with shocking regularity. NPM tends to reinforce the worst of the JS world's tendencies.

> Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe Do you have any evidence to back up this statement, compared to developers in other languages? Or is this just business-as-usual JS bashing?

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.

Re: Malicious code in the purescript NPM installer

#45

Post by krainboltgreene » Sun, Jul 28, 2019, 9:42 PM UTC

jonas21 wrote: post #37

hobofan wrote: post #31

Earlier quoted context omitted.

That's not a "solution". That's just shifting the trust to a different (smaller) group of people.

> That's just shifting the trust to a different (smaller) group of people. Practically speaking, shifting trust from a large, anonymous group of people, to a small group of people who are known and trusted by the community is a pretty good solution.

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

Re: Malicious code in the purescript NPM installer

#46

Post by z3t4 » Sun, Jul 28, 2019, 9:43 PM UTC

kreetx wrote: post #41

z3t4 wrote: post #16

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.

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?

Take the most popular npm module lodash for example. It has over one thousand files! But you probably only need one (lodash.js) and that's the one I would commit to SCM.

Re: Malicious code in the purescript NPM installer

#47

Post by Operyl » Sun, Jul 28, 2019, 9:45 PM UTC

JulianMorrison wrote: post #9

hn_throwaway_99 wrote: post #5

Earlier quoted context omitted.

I think the blog author is implying as much as he can, without directly accusing, that he believes that https://github.com/shinnn was responsible for the bad code, not a random hack.

2FA would also make it much harder to use the "somebody hacked me" defense.

No at that point they'd be saying "zomg NPM has a terrible bug that allowed the hacker to bypass my 2FA!"

If someone is trying to redirect blame they'll always find some way to do so.

Re: Malicious code in the purescript NPM installer

#48

Post by pvg » Sun, Jul 28, 2019, 9:47 PM UTC

neilv wrote: post #34

pvg wrote: post #25

Earlier quoted context omitted.

they piggybacked onto the existing DNS domain name control It's a recommended and widely-followed voluntary naming scheme - it's not in any way connected to domain name control.

I should've been more clear about what I was saying with "control". The recommendation is connected directly to domain names you control. What was not done at the time was enforcing that, or using that as a basis of authentication or distribution, which is part of why I said more could be done, today.

The purpose of the scheme was to make namespace collisions less likely and that's about it, though. And people regularly deviate from it, both then and now. Not using it as a basis for authentication or distribution probably remains a really excellent idea.

Re: Malicious code in the purescript NPM installer

#49

Post by Ayesh » Sun, Jul 28, 2019, 9:51 PM UTC

McGlockenshire wrote: post #13

hombre_fatal wrote: post #6

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

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

PHP dependency management (composer and packagist) got many things right, such as namespaces packages, lock files, proper autoloading, etc.

Re: Malicious code in the purescript NPM installer

#50

Post by dcbadacd » Sun, Jul 28, 2019, 10:01 PM UTC

braythwayt wrote: post #4

ga-vu wrote: post #3

Not actually malicious. It doesn't steal user data, drop malware, or damage a computer. Just crashes the library. Looks like another developer-developer slap fight.

I beg your pardon, but if I am using this library as part of a shipping piece of software-as-a-service, and I am in the middle of shipping a new feature when suddenly things mysteriously crash... If I later discover that the crash was put there deliberately, I am going to call that malice, and malice that has directly impacted a functioning business and its customers. It's no different than a disgruntled person putti…

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 from the internet? Why do you do so with the dependencies for your projects and expect a better end result? You may not like to hear this but it's true.

There's two solutions here, either you start reviewing the libraries you use, every release, or sign a support contract that obliges the maintainer to do something you want.