Malicious code in the purescript NPM installer • Hacker News Board

Re: Malicious code in the purescript NPM installer

#11

Post by johnchristopher » Sun, Jul 28, 2019, 8:10 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…

> 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 to have code free of malice in the current javascript ecosystem ?

Re: Malicious code in the purescript NPM installer

#12

Post by btown » Sun, Jul 28, 2019, 8:10 PM UTC

hn_throwaway_99 wrote: post #5

bsamuels wrote: post #2

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

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.

To quote the article: "As far as we are aware, the only purpose of the malicious code was to sabotage the purescript npm installer to prevent it from running successfully... the purpose of this condition [in the code, hardcoded to include the word 'cli'] seems to be to ensure that the malicious code only runs when our installer is being used (and not @shinnn’s)."

:hmm:

Re: Malicious code in the purescript NPM installer

#13

Post by McGlockenshire » Sun, Jul 28, 2019, 8:11 PM UTC

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.

Re: Malicious code in the purescript NPM installer

#14

Post by dane-pgp » Sun, Jul 28, 2019, 8:13 PM UTC

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…

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

Re: Malicious code in the purescript NPM installer

#15

Post by hombre_fatal » Sun, Jul 28, 2019, 8:16 PM UTC

JulianMorrison wrote: post #8

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.

It's childish and amounts to an indirect attempt at damaging the reputation of the compiler maintainers. It's playing fast and loose with everyone who needs an install up and working for reasons. I'd say there was a heap of malice and it reflects very badly on mister "someone gained access to my account".

It's truly mind-blowing how this @shinnn character chose to handle this. It's so petty that I would actually have more respect for them had they snuck in something more devastating, like scanning for bitcoin privkeys.

Re: Malicious code in the purescript NPM installer

#16

Post by z3t4 » Sun, Jul 28, 2019, 8:17 PM UTC

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.

Re: Malicious code in the purescript NPM installer

#17

Post by johnchristopher » Sun, Jul 28, 2019, 8:22 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.

> Just crashes the library.

Which damages everything that relies on it, so... Yeah, malicious (as in `malice` and as in `let's hide it`).

Re: Malicious code in the purescript NPM installer

#18

Post by neilv » Sun, Jul 28, 2019, 8:41 PM UTC

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…

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

Re: Malicious code in the purescript NPM installer

#19

Post by trabant00 » Sun, Jul 28, 2019, 8:43 PM UTC

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…

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.

Re: Malicious code in the purescript NPM installer

#20

Post by Fellshard » Sun, Jul 28, 2019, 8:44 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.

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.