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

261–270 of 279 posts

Re: Malicious code in the purescript NPM installer

#261

Post by munificent »

gridlockd wrote: post #242
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…

> The problem is that ownership, and even names of owners change all the time. If ownership changes, I want to know . It's perfectly fine to cause a little bit of breakage there that is easily fixed in a semi-automated, supervised way. If a name changes, there could just be an alias, unless there's literally a trademark dispute underway, in which case the ownership-change process can be applied. > When you have very…

> is easily fixed in a semi-automated, supervised way.

It's not. Once you have shared, transitive dependencies, the application author consuming a package is no longer the one who authored or is in control of the dependency on that transferred package.

> A very large transitive dependency graph is a terrible thing to have.

This is a fair subjective preference. Unfortunately, it flies in the face of reality. Anyone who maintains a package manager will tell you real-world package graphs are typically quite large and deep. If users didn't want that, they wouldn't do it.

> Your package manager should scold you for it!

Users don't generally like or use tools that scold them for doing what they want to do.

Re: Malicious code in the purescript NPM installer

#262

Post by filleduchaos »

xeonoex wrote: post #252
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.

I'm not sure that you understand what .NET is. .NET is a platform/ecosystem. I was talking about packages. Packages are managed by nuget, which works across all .NET languages, which is why I didn't specify a language.

Framework, platform, ecosystem, SDK, etc: you're rather neatly sidestepping the point that you're comparing not a programming language to programming languages. A fair comparison would be C# to Java, or Javascript.

What Microsoft chooses to call the .NET Standard Libraries is not at all the same thing as a language's standard library.

Re: Malicious code in the purescript NPM installer

#263

Post by allover »

kkapelon wrote: post #237
allover wrote: post #233

Earlier quoted context omitted.

1) Same applies for npm (granted, this was only fixed after the left-pad incident, and npm was not the only language's registry to have that issue). 2) As mentioned elsewhere in this thread, npm supports namespaced packages, but they are not mandatory. There are other major languages' registries in same situation. 3) Can you back up 'nobody'. I would suspect a lot of companies don't use a proxy. Some JS teams also us…

1) The fact that an incident actually forced something that Maven registry did since inception, doesn't actually reinfornce the original argument? (that JS developers did not look at what other languages were doing already) 2) Again, whoever thought that namespaces should be optional instead of required "doesn't seem to be aware of the rest of the software universe". Who took this decision? Why? 3) Do a survey on you…

1) As I said, it was not just JS in this situation at the time, it also applied to other major registries like PyPi. So your point does not reinforce the original attack on JS developers. Congrats to Maven for getting this right.

2) Namespaces were added later. It wasn't "a decision to make them optional". Also check out for the discussion here as to how namespaces don't solve this issue, this point is largely moot.

3) I'm not the person blanket attacking a community. Or making unlikely assertions that "nobody" in the Java world installs direct from the internet.

4) Detail the exploit, otherwise this is FUD.

Re: Malicious code in the purescript NPM installer

#264

Post by adev_ »

geofft wrote: post #255
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…

Nobody is closing their eyes and singing "everything is fine." A large number of small packages is a good thing, and a technically strong ecosystem supports it. Having spent the last week in the internals of glibc chasing bugs in code that has no reason to be jammed into the same library that handles initial program loading, I can attest that there are good, justifiable, technical reasons to do things the NPM way, an…

> I know it's hard for you to imagine, but perhaps the JavaScript ecosystem has some good things about it.

There is good in very ecosystem. But a simple keyword "node_modules" on twitter should probably convince you that the good of JS is not in its package system.

To be fair, even the NodeJS author agree on that.

Modularity does not mean "split your code at the atomic level".

Re: Malicious code in the purescript NPM installer

#265

Post by inimino »

fock wrote: post #231
inimino wrote: post #214

Earlier quoted context omitted.

You're being downvoted because that is mean-spirited, but the reason we needed these packages is to find out what the right size of package is. We now have a lower bound.

I'm not sure what's mean-spirited about the simple statement that the size/complexity of the npm-eco-system arises only from personal/corporate business-decisions. But thanks for telling me anyways ;)

Business decisions and marketing are not the only reasons people write open source software and you would do well to remember it.

Re: Malicious code in the purescript NPM installer

#266

Post by liveoneggs »

naniwaduni wrote: post #120
School-Cotton wrote: post #110

Earlier quoted context omitted.

I’m not a JS developer so maybe I’m missing something, but how do you use a library during development and not use it in production? In the C++ world, I can’t imagine a situation where you would need to depend on, for example, libjpg while developing, but not need to read JPEG files in prod/end-user-space.

In the C++ world, you almost certainly don't need headers in prod.

headers are not libraries

Re: Malicious code in the purescript NPM installer

#267

Post by [deleted] »

oblio wrote: post #248
allover wrote: post #202

Earlier quoted context omitted.

> Even PHP gets this right. It's not hard. PHP had the luxury of coming out with a package manager (Composer) later, and learning from others before it. (2012 vs 2010 for npm). Npm similarly improved on a lot of package managers that came before (e.g it's superior to Pip, which doesn't resolve dependencies [1]). > It makes me wonder why npm hasn't already moved to namespaced package names. Also, npm does have namespa…

Apache Maven was released in 2004... PHP just looked at what Java was doing. Might be a wrong idea for some things but it definitely helps for stuff such as package management.

[deleted]

Re: Malicious code in the purescript NPM installer

#268

Post by allover »

gridlockd wrote: post #244
_pmf_ wrote: post #185

Earlier quoted context omitted.

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

I think the problem is that Java people are considered "old and lame", whereas the Javascript people are considered "young and immature", respectively. While this assessment is somewhat accurate, it inhibits the process of learning from each other.

> While this assessment is somewhat accurate

No it isn't, and please stop perpetuating this nonsense.

Re: Malicious code in the purescript NPM installer

#269

Post by kkapelon »

allover wrote: post #263
kkapelon wrote: post #237

Earlier quoted context omitted.

1) The fact that an incident actually forced something that Maven registry did since inception, doesn't actually reinfornce the original argument? (that JS developers did not look at what other languages were doing already) 2) Again, whoever thought that namespaces should be optional instead of required "doesn't seem to be aware of the rest of the software universe". Who took this decision? Why? 3) Do a survey on you…

1) As I said, it was not just JS in this situation at the time, it also applied to other major registries like PyPi. So your point does not reinforce the original attack on JS developers. Congrats to Maven for getting this right. 2) Namespaces were added later. It wasn't "a decision to make them optional". Also check out for the discussion here as to how namespaces don't solve this issue, this point is largely moot.…

4) You work for a Linux distribution. You have several global npm modules already installed that are safe and secure. You download source code of a killer app in order to package it. You check the source code itself and it is safe. However you didn't realize that there was a local node_modules directory in the git repo that contains package foo-1.2.3 with replaced code that does bad things. That package overrides your global one. You ship a compromised app.

The above scenario is impossible with maven, because there is no concept of local modules. Only the "global" ones will be used when you package an app. So if you check just the source code and it is safe then everything is fine.

Re: Malicious code in the purescript NPM installer

#270

Post by xeonoex »

filleduchaos wrote: post #262
xeonoex wrote: post #252

Earlier quoted context omitted.

I'm not sure that you understand what .NET is. .NET is a platform/ecosystem. I was talking about packages. Packages are managed by nuget, which works across all .NET languages, which is why I didn't specify a language.

Framework, platform, ecosystem, SDK, etc: you're rather neatly sidestepping the point that you're comparing not a programming language to programming languages . A fair comparison would be C# to Java, or Javascript. What Microsoft chooses to call the .NET Standard Libraries is not at all the same thing as a language's standard library.

How is that relevant at all? We're talking about package management. .NET uses nuget. Let's look at the nuget site:

https://www.nuget.org/

> NuGet is the package manager for .NET.

So my point is invalid because I wrote .NET instead of C#/VB/F#? You might want to contact nuget to tell them their site is wrong too then.

My point is that finding quality packages is easier with nuget than the JS or Java package managers. And using them is usually easier too. It's a fair comparison.

Post reply on HN