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

101–110 of 279 posts

Re: Malicious code in the purescript NPM installer

#101

Post by danShumway »

braythwayt wrote: post #4
ga-vu wrote: post #3

Not actually malicious. It doesn't steal user data, drop malware, or damage a computer. Just crashes the library. Looks like another developer-developer slap fight.

I beg your pardon, but if I am using this library as part of a shipping piece of software-as-a-service, and I am in the middle of shipping a new feature when suddenly things mysteriously crash... If I later discover that the crash was put there deliberately, I am going to call that malice, and malice that has directly impacted a functioning business and its customers. It's no different than a disgruntled person putti…

It's malicious.

That being said, I always get pushback when I mention this but I think SaaS projects should often be vendoring dependencies. It's safer, it's more secure, it gives you more consistent installs -- and it prevents `leftpad` scenarios. It makes source control slightly more complicated, but the other benefits (often) greatly outweigh that.

This is something that used to be more commonplace in the Javascript community, and it's something that `node_modules` makes very easy, but it's fallen out of style in modern web development.

To the best of my knowledge, this was also commonplace in the original design of Go, since it was coming out of Google, which does vendor all of its dependencies. I'm not sure which way the current Go community leans.

Re: Malicious code in the purescript NPM installer

#102

Post by hnbroseph »

braythwayt wrote: post #4
ga-vu wrote: post #3

Not actually malicious. It doesn't steal user data, drop malware, or damage a computer. Just crashes the library. Looks like another developer-developer slap fight.

I beg your pardon, but if I am using this library as part of a shipping piece of software-as-a-service, and I am in the middle of shipping a new feature when suddenly things mysteriously crash... If I later discover that the crash was put there deliberately, I am going to call that malice, and malice that has directly impacted a functioning business and its customers. It's no different than a disgruntled person putti…

it would also be some contributory negligence if someone is shipping a service that just grabs and includes unsigned/unvetted/untested code from the internet as a component...

Re: Malicious code in the purescript NPM installer

#103

Post by School-Cotton »

GordonS wrote: post #56
hedora wrote: post #54

Earlier quoted context omitted.

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

A lot of those packages are going to be versions months or sometimes years behind the latest version. I'm not convinced this is a model that can work for programming libraries.

It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine.

Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.

Re: Malicious code in the purescript NPM installer

#104

Post by School-Cotton »

SCLeo wrote: post #79
hedora wrote: post #54

Earlier quoted context omitted.

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

Honestly, I think the reliability of those packages are not guarded by these people, but rather by the corresponding communities of those packages. If one of the community failed to secure its package from malicious people, these people at debian are not going to be able to stop it. Thus, those packages are still guarded by a huge community.

Why do you think this? OSes like Debian don’t just pull packages from upstream automatically. Packages have actual maintainers affiliated with the OS, not the upstream community, and it’s those maintainers who build packages for the OS repos.

Re: Malicious code in the purescript NPM installer

#105

Post by School-Cotton »

kjksf wrote: post #71
naniwaduni wrote: post #61

Earlier quoted context omitted.

npm's size is not independent of its curation strategy. This can be construed as a good or a bad thing.

NPM's size is first and foremost dependent on the popularity of JavaScript. All other "modern" (where "modern" is "last 20 years") package managers have zero curation. Perl, Python, Ruby, Go, Rust, Dart, JavaScript. You say: "if they had curation, they would be better". I say: "if they had curation, they would have lost to a competitor that doesn't have curation". People care about having more packages much more than…

> modern

Apt is about 20 years old, and the most famous apt package repos (I.e., the Ubuntu project) is much younger than that.

Re: Malicious code in the purescript NPM installer

#106

Post by steveklabnik »

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.

Cargo is more like npm than Bundler in this regard, as Bundler does not let you have multiple versions of a package at the same time. That lesson was learned from npm, though implemented in a different way.

Re: Malicious code in the purescript NPM installer

#107

Post by School-Cotton »

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…

> that friction will drastically slow down the ecosystem

This is a feature.

Re: Malicious code in the purescript NPM installer

#108

Post by soulofmischief »

School-Cotton wrote: post #103
GordonS wrote: post #56

Earlier quoted context omitted.

A lot of those packages are going to be versions months or sometimes years behind the latest version. I'm not convinced this is a model that can work for programming libraries.

It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine. Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.

But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.

Re: Malicious code in the purescript NPM installer

#109

Post by TeMPOraL »

kjksf wrote: post #71
naniwaduni wrote: post #61

Earlier quoted context omitted.

npm's size is not independent of its curation strategy. This can be construed as a good or a bad thing.

NPM's size is first and foremost dependent on the popularity of JavaScript. All other "modern" (where "modern" is "last 20 years") package managers have zero curation. Perl, Python, Ruby, Go, Rust, Dart, JavaScript. You say: "if they had curation, they would be better". I say: "if they had curation, they would have lost to a competitor that doesn't have curation". People care about having more packages much more than…

People care about having more packages much more than abstract fears of security or quality of those packages.

At their own peril.

Re: Malicious code in the purescript NPM installer

#110

Post by School-Cotton »

soulofmischief wrote: post #108
School-Cotton wrote: post #103

Earlier quoted context omitted.

It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine. Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.

But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.

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.

Post reply on HN