Malicious code in the purescript NPM installer • Hacker News Board

Re: Malicious code in the purescript NPM installer

#31

Post by hobofan » Sun, Jul 28, 2019, 9:13 PM UTC

trabant00 wrote: post #19

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

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

Re: Malicious code in the purescript NPM installer

#32

Post by matthewbauer » Sun, Jul 28, 2019, 9:13 PM UTC

trabant00 wrote: post #19

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

That comes at a cost of lots of volunteer hours. I’m not sure if it would scale to NPM’s massive size.

Re: Malicious code in the purescript NPM installer

#33

Post by allover » Sun, Jul 28, 2019, 9:15 PM UTC

Fellshard wrote: post #20

McGlockenshire wrote: post #13

Earlier quoted context omitted.

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.

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

Re: Malicious code in the purescript NPM installer

#34

Post by neilv » Sun, Jul 28, 2019, 9:15 PM UTC

pvg wrote: post #25

neilv wrote: post #18

Earlier quoted context omitted.

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

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.

Re: Malicious code in the purescript NPM installer

#35

Post by twic » Sun, Jul 28, 2019, 9:16 PM UTC

geofft wrote: post #24

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.

Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does, so that doesn't seem to be the explanation here.

cargo, at least, does this for the reason Fellshard gives - the Rust team essentially commissioned a copy of Ruby's bundler, without considering whether there was anything to learn from any other language's ecosystem.

Re: Malicious code in the purescript NPM installer

#36

Post by geofft » Sun, Jul 28, 2019, 9:17 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…

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.

Re: Malicious code in the purescript NPM installer

#37

Post by jonas21 » Sun, Jul 28, 2019, 9:18 PM UTC

hobofan wrote: post #31

trabant00 wrote: post #19

Earlier quoted context omitted.

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

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.

Re: Malicious code in the purescript NPM installer

#38

Post by geofft » Sun, Jul 28, 2019, 9:19 PM UTC

twic wrote: post #35

geofft wrote: post #24

Earlier quoted context omitted.

Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does, so that doesn't seem to be the explanation here.

cargo, at least, does this for the reason Fellshard gives - the Rust team essentially commissioned a copy of Ruby's bundler, without considering whether there was anything to learn from any other language's ecosystem.

Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages and reinventing the wheel, I'm not sure what words mean anymore.

Re: Malicious code in the purescript NPM installer

#39

Post by nightkoder » Sun, Jul 28, 2019, 9:22 PM UTC

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.

Re: Malicious code in the purescript NPM installer

#40

Post by SanchoPanda » Sun, Jul 28, 2019, 9:24 PM UTC

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.