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

221–230 of 279 posts

Re: Malicious code in the purescript NPM installer

#221

Post by blauekapelle »

ricardobeat wrote: post #100
gitgud wrote: post #86

NPM gets a lot of hate for it's dependency managemnet, but I'm not sure what a solution would be to this problem. - They can't currate packages, or else that friction will drastically slow down the ecosystem (1000's of packages get published everyday). - They can't remove/disable packages (most of the time) , or dependencies will no longer be strictly immutable. - They can't disable sub-dependencies, or else this wou…

After 10 years of nodejs I can honestly say I wouldn’t mind the friction. NPM is a wasteland of abandoned packages and reinventing the wheel. They never solved discovery so you have 500x implementations of the exact same thing. Around 2015 we passed the point where looking for the “right” package takes longer than writing your own.

not to mention you can have a middle ground with a curated list and an open repository - think arch user repository

Re: Malicious code in the purescript NPM installer

#222

Post by rjmunro »

runeks wrote: post #177

The work “exploit” is used several times but none of the code seems to exploit anything. Also, “malicious code” usually has a different meaning than something that intentionally makes the program crash during the installation process.

I feel like this is only part of a wider attack - like by causing this not to download, it meant that users do some other action which opens them up to the real attack.

Re: Malicious code in the purescript NPM installer

#224

Post by braythwayt »

yawaramin wrote: post #95
braythwayt wrote: post #55

Earlier quoted context omitted.

You are not a lawyer, because if you were, you would be aware that there is case law establishing that just because you don't charge for it, doesn't mean you aren't providing an implied warranty and aren't taking implied liability. There is absolutely zero chance that you can put malware into an open source project, give it away, and then when sued, stand up and say, "It was free, what do people expect?" You can call…

> just because you don't charge for it, doesn't mean you aren't providing an implied warranty and aren't taking implied liability. Open source software is almost always distributed with a license that explicitly disavows any such warranty or liability. This is pretty widely understood...

Just because you put it in a license, doesn't mean it will hold up in court.

Example: I distribute a flashlight app. It contains an obfuscated bitcoin miner and a MITM that collects your login credentials. My license does not mention ether of these things, but it does say there is no warranty or liability.

What do you think will happen if I am sued in court and/or charged with a crime?

Re: Malicious code in the purescript NPM installer

#225

Post by tjpnz »

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.

>The gains are small but quickly add up.

Same could also be said for build times not to mention security issues should one of your micro-dependencies be hijacked.

Re: Malicious code in the purescript NPM installer

#226

Post by _pmf_ »

_pmf_ wrote: post #185
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…

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

On further reading, it's debatable whether the "maliciousness" is not the community attempting to take away a project from its founder. Similar to how that toxic Twisted dev tried to push responsibility for maintaining their broken branch of Python 2 to the Python core lib dev.

You can fork, but then you're responsible for more than the "fun parts". The project founder might introduce measures to prevent fragmentation due to your bad decisions as part of damage control.

Re: Malicious code in the purescript NPM installer

#227

Post by efdee »

mschuster91 wrote: post #166
filleduchaos wrote: post #128

Earlier quoted context omitted.

> I know it's not a 100% fair comparison, since I am biased. It might also have something to do with you apparently unironically comparing a framework to a programming language.

.net is both framework and language, for the framework comes with the language.

.NET is not a language at all.

C# is, VB.NET is, F# is. .NET, not as much.

Re: Malicious code in the purescript NPM installer

#228

Post by littlestymaar »

davnicwil wrote: post #219
littlestymaar wrote: post #216

Earlier quoted context omitted.

> Also, would there be a pointer built in that let you know about the new owner namespace when you try to upgrade automatically? And what would be the point of the namespace then ?

> pkg upgrade @person-a/some-package "You're on the latest version 1.2.3 of @package-a/some-package, however @person-a has officially transferred ownership of some-package to @person-b and there is a newer version 1.2.4 available at @person-b/some-package. If you'd like to upgrade, please update your dependency to @person-b/some-package"

That's the mechanism, I was asking about the benefit of namespace in that case. With this kind of ownership transfers you lose all the alleged security benefit of namespaces.

Re: Malicious code in the purescript NPM installer

#229

Post by delfaras »

rjmunro wrote: post #220
delfaras wrote: post #178

Earlier quoted context omitted.

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 $/, ''); }; ```

That code doesn't match what actually happens. It will only trim a single character. Have asterisks been trimmed in your copy-paste or something?

Ah you're right, the asterisks have been interpreted as italics. Can't edit my comment, sorry

Here's a paste: https://pastebin.com/kBHprdyj

Re: Malicious code in the purescript NPM installer

#230

Post by LoSboccacc »

littlestymaar wrote: post #212
twic wrote: post #207

Earlier quoted context omitted.

> a large number of skilled people > RubyGems Well, which is it? Java has used namespaced packages since 1996, and it's been a roaring success. There have certainly been problems - for example, there is currently some absolute nonsense going on about the handover of big chunk of stuff from Oracle to the Eclipse Foundation [1] - but they have always been manageable, and don't come close to outweighing the benefits. [1…

Java was indeed a success, but its dependency management is archaic at best. Yes it's better than FORTRAN or C, but I wouldn't use it as a reference in 2019…

it's signed, hierarchical, decentralized, supports addressing multiple artifacts within the same module by type, includes a standardized way to retrieve sources or docs, supports pinning the version of transitive dependencies so you can manually resolve conflicts and on top of that can be extended to use completely alien package sources (which is unholy if you ask me, but it helped me survive the great osgi catastrophe of the 2010s thanks to tycho)
Post reply on HN