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

181–190 of 279 posts

Re: Malicious code in the purescript NPM installer

#181

Post by sterlind »

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…

You could go farther and use a DNS name as a group name, then publish packages by signing with the SSL key. Anyone who doesn't want to shell out for a domain name could use a registry service that gives subdomains out. Why reinvent the governance wheel?

Re: Malicious code in the purescript NPM installer

#182

Post by m90 »

adev_ wrote: post #172
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.

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

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

This is not something inherent to npm itself, it's what the people using npm choose to publish.

No matter if people like small modules or not, it's not at all related to the topic discussed.

Re: Malicious code in the purescript NPM installer

#183

Post by akerl_ »

thetrainfold wrote: post #180
akerl_ wrote: post #176

Earlier quoted context omitted.

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?

For what it’s worth, I think I actually like the idea of mandating a 2-part namespace, as the way to force “long” names (where “long” means “with enough context to make forking easier and more obvious”). I just wanted to call out that “force namespacing” isn’t a silver bullet for the issue.

A better feature-add might be supporting dependency replacements. For example, pre-modules, Go had an issue where if you had a dependency and I forked it, I had to go through all my code and replace references to your import path with mine. If I depended on something that depended on you, I was out of luck (or had to vendor and regex or a variety of other hacks). Now, with go modules, I can do a “replace” in my go.mod and sub in my fork for yours. That has enabled me to be much more flexible with my use of forked repositories, and most languages don’t have a direct parallel.

Re: Malicious code in the purescript NPM installer

#184

Post by fock »

krainboltgreene wrote: post #45
jonas21 wrote: post #37

Earlier quoted context omitted.

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

Tell me, why one needs packages such as this except for personal (and ultimately npm) marketing: https://github.com/sindresorhus/shebang-regex - the whole thing smells

Re: Malicious code in the purescript NPM installer

#185

Post by _pmf_ »

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…

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

The Maven ecosystem has been doing things better than NPM for at least 10 years. The onus is on the NPM team for justifying their pathologically bad solution, it's also on the JS community to back off their "everybody can contribute" pipe dream. Maven works because in practice, we have some few organizations contributing packages, not thousands of individual, anonymous developers.

Re: Malicious code in the purescript NPM installer

#186

Post by LoSboccacc »

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…

> this change of ownership is an implementation detail that doesn't need to impact package consumers

it does, because having a dependency means having a trusted path from the developer to the packager to the repository into your software and to your customers

frankly you'd want to do what you call "constant pointless churn" at every single version update, because god knows what comes trough your package manager, as this and many other articles pointed out repeatedly, and the fact that you are advocating to skip it not for version changes but for whole ownership changes is the opposite of a security oriented mindset.

Re: Malicious code in the purescript NPM installer

#187

Post by fock »

jasonhansel wrote: post #82
svnpenn wrote: post #80

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

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

well, the rate-map at least includes a function: https://github.com/sindresorhus/shebang-regex

Re: Malicious code in the purescript NPM installer

#188

Post by adev_ »

m90 wrote: post #182
adev_ wrote: post #172

Earlier quoted context omitted.

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

> None of them have chosen the "micro-package" way of NPM. This is not something inherent to npm itself, it's what the people using npm choose to publish. No matter if people like small modules or not, it's not at all related to the topic discussed.

> No matter if people like small modules or not, it's not at all related to the topic discussed.

It is very relevant to the topic discussed.

Just for fun :

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

> 150 dependencies.

Including a package named "one-time", bundled several times in two different versions. To do something highly relevant and technical like "Call a function once".

I have no doubt that it is an Highly complex code that requires indeed two packages..... Irony

Little question: What would have been the probability of purescript getting malicious if its dependency tree would be something reasonnable... Let's say 20 packages instead of the current ~200 ?

Re: Malicious code in the purescript NPM installer

#189

Post by vhakulinen »

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.

> it’s code already written and tested by > 1 person, edge cases already figured out.

It is tested? Edge cases figured out? Essentially for this code?:

    return start + val * (end - start);
Sure, if its running in hostile environment, you might need to do those sanity checks for your parameters - but I have hard time imagining such situation. If you actually need to "Map a number in the range of 0-1 to a new value with a given range" in your own code, can't you guarantee that the variables are all numbers? Its your responsibility as a developer to know your code, and the data your code is handling.

> Saves you time.

There is something really wrong if finding a package to do this niche thing is faster and more optimal that just writing out that one line of code.

Re: Malicious code in the purescript NPM installer

#190

Post by Corrado »

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.

I beg to differ; witness the fibur[0] Ruby Gem. Written by Arron Patterson (@tenderlove) to show that using threads in Ruby is very easy. The Gem consists of this single line:

   Fibur = Thread
Of course, he did it as a joke, and it doesn't excuse the serious packages that NPM contains, but it does prove that other languages have single line packages.

[0] https://rubygems.org/gems/fibur

Post reply on HN