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

171–180 of 279 posts

Re: Malicious code in the purescript NPM installer

#171

Post by pjc50 »

munificent wrote: post #151
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…

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

But every change of ownership is a potential mass security compromise.

Re: Malicious code in the purescript NPM installer

#172

Post by adev_ »

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.

> Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does

Wrong.

None of them have chosen the "micro-package" way of NPM.

None of them have an average size of "3-10" line of code per package, which NPM has for many MANY packages. Cargo, pip have many packages but "reasonnable size" packages. ( > 100 lines ).

The Micro-package philosophy that NPM chose, meaning every single line of code can have its own package, increase by several factor the number of dependencies required to create anything in JS.

A simple hello world in react already have ~100 dependencies

https://npm.anvaka.com/#/view/2d/react-create-app

Some core utility bundler/packer/etc overpasses 2000 dependencies

https://npm.anvaka.com/#/view/2d/webpack

This is madness.

It is a simple evidence that bigger the dependency tree is, higher the chance of "one element" malicious / corrupted is.

Maybe the NPM developpers / users should reflect on what lead to this situation instead of closing their eyes and sing "everything is fine".

Re: Malicious code in the purescript NPM installer

#174

Post by cannedslime »

ricardobeat wrote: post #98
SCLeo wrote: post #81

Earlier quoted context omitted.

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.

What gains? That line wouldn't take much resources or time to figure out and test. Now you have yet another dependency that could be injected with bad code in the future...

Re: Malicious code in the purescript NPM installer

#175

Post by reeeeee »

GrumpyNl wrote: post #168
SCLeo wrote: post #81

Earlier quoted context omitted.

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.

You should take a look at the trim package and how often hat is downloaded.

There is not even a link to the source code on the npm page for it. I installed it and inspected the source code, but I doubt everyone does this when installing a dependency.

Re: Malicious code in the purescript NPM installer

#176

Post by akerl_ »

hardwaresofton wrote: post #170
munificent wrote: post #151

Earlier quoted context omitted.

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

It seems like a reasonable fix to this is to prevent name-specific owning (changing it to a group instead) -- this has the benefit that package maintainers who plan to maintain their packages forever can keep the same names, and those that don't can essentially fork their project and stop fixing the older version (@ / ) and force all changes to go to a new one (@ / ) and hand off ownership as necessary. This doesn't…

As a thought experiment:

Assume Rubygems chose to operate in that way, where all gems must be owned by a group rather than an individual user.

Then, assume that the most flexible option is for each gem to be owned by a unique group: that way even if two gems are maintained by the same users right now, they use two distinct groups in case that ownership changes in the future.

We might as well just name the “group” the same as the gem name, since only one gem is managed by each group. So now the “purescript” group maintains “purescript”, the “pry” group maintains “pry”, etc.

As syntactic sugar for users, since the group name and gem name will always match, why make them type both? Let’s have all the commands support just referencing the gem name. If somebody wants to fork a gem and release it, their group and gem get a new name.

I think there’s a pretty compelling case that package managers should support group ACLing on publishing (giving multiple humans the first-class right to publish using individual creds to a group namespace, with the ability to add/remove users from the group over time. But once you’ve done that, the distinction between explicit group-name-in-package-path and changing-name-to-fork (so the difference between fork-group/orig-name and orig-name_fork-group) seems to shrink.

Re: Malicious code in the purescript NPM installer

#178

Post by delfaras »

reeeeee wrote: post #175
GrumpyNl wrote: post #168

Earlier quoted context omitted.

You should take a look at the trim package and how often hat is downloaded.

There is not even a link to the source code on the npm page for it. I installed it and inspected the source code, but I doubt everyone does this when installing a dependency.

Here's the complete source for anyone curious

``` exports = module.exports = trim;

function trim(str){ return str.replace(/^\s|\s$/g, ''); }

exports.left = function(str){ return str.replace(/^\s/, ''); };

exports.right = function(str){ return str.replace(/\s$/, ''); };

```

Re: Malicious code in the purescript NPM installer

#179

Post by SahAssar »

pjmlp wrote: post #160
allover wrote: post #33

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

For starters, developers in other language communities don't publish packages for single line functions.

That's a philosophical difference which says nothing of their understanding of the rest of the software universe.

I dislike the microdependencies and the "DRY-taken-to-the-extreme" stuff that the js community does but your argument does not hold up.

Re: Malicious code in the purescript NPM installer

#180

Post by thetrainfold »

akerl_ wrote: post #176
hardwaresofton wrote: post #170

Earlier quoted context omitted.

It seems like a reasonable fix to this is to prevent name-specific owning (changing it to a group instead) -- this has the benefit that package maintainers who plan to maintain their packages forever can keep the same names, and those that don't can essentially fork their project and stop fixing the older version (@ / ) and force all changes to go to a new one (@ / ) and hand off ownership as necessary. This doesn't…

As a thought experiment: Assume Rubygems chose to operate in that way, where all gems must be owned by a group rather than an individual user. Then, assume that the most flexible option is for each gem to be owned by a unique group: that way even if two gems are maintained by the same users right now, they use two distinct groups in case that ownership changes in the future. We might as well just name the “group” the…

Could it help to force long names, preventing simple, 'elegant' names?
Post reply on HN