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

151–160 of 279 posts

Re: Malicious code in the purescript NPM installer

#151

Post by munificent »

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 majority of cases, this change of ownership is an implementation detail that doesn't need to impact package consumers. If you enshrine the owner's name in the package, it means any change of ownership is effectively a breaking change to the package. When you have very large transitive dependency graphs, the result is constant, pointless churn.

Re: Malicious code in the purescript NPM installer

#152

Post by MaulingMonkey »

robocat wrote: post #130
z3t4 wrote: post #16

Before "tree shaking" I stored all npm modules in SCM and reviwed all updates as I had to commit after "npm update". I also put ton of files in .ignore as 90% of files in some packages are not required. I also used to include npm modules in distribution/deployment. So my request to npm is to add an option in the main package.json to disable tree shaking.

I wish there was a way to "bless" packages when they were reviewed. I want a network of trust, such that a Google reviewed package is worth 10 points, a package fuzzed by foobar is worth 2 points, something skimmed by a dependant user is worth 1 point etc. I can then chose a compromise between a highly rated/reviewed dependencies and functionality/risk/cost-to-review. My own blessing of a package I have reviewed migh…

For Rust there is at least one tool for this that I've started using, although I don't think it's very widely used: https://github.com/dpc/crev/tree/master/cargo-crev

Ironically this depends on a whole slew of additional packages I haven't yet reviewed to build ;)

Very recently (2 commits starting 8 days ago) someone started on an npm equivalent but it's not in a usable state yet: https://github.com/kspaans/npm-crev/blob/master/TODO.md

Two problems - few people out there reviewing code, and poor discoverability for who else is reviewing code that you might trust at the moment.

Re: Malicious code in the purescript NPM installer

#153

Post by yaa_minu »

robocat wrote: post #130
z3t4 wrote: post #16

Before "tree shaking" I stored all npm modules in SCM and reviwed all updates as I had to commit after "npm update". I also put ton of files in .ignore as 90% of files in some packages are not required. I also used to include npm modules in distribution/deployment. So my request to npm is to add an option in the main package.json to disable tree shaking.

I wish there was a way to "bless" packages when they were reviewed. I want a network of trust, such that a Google reviewed package is worth 10 points, a package fuzzed by foobar is worth 2 points, something skimmed by a dependant user is worth 1 point etc. I can then chose a compromise between a highly rated/reviewed dependencies and functionality/risk/cost-to-review. My own blessing of a package I have reviewed migh…

You may find npms.io[1] useful. For each package, they provide a score on maintainability, popularity and quality.

[1] https://npms.io

Re: Malicious code in the purescript NPM installer

#154

Post by dmitriid »

SCLeo wrote: post #81
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...

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.

Funnily enough, in my opinion, the JS ecosystem fully embraced the Unix way: have small programs/libs that do only one thing and do it (somewhat) well.

Re: Malicious code in the purescript NPM installer

#155

Post by Xylakant »

voltagex_ wrote: post #148
gregmac wrote: post #129

Earlier quoted context omitted.

> 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. If things are "randomly changing" by updates, that means the upstream package isn't following semantic versioning practices, and more importantly, isn't preserving backwards compatibility with their releases. That's a mark of bad softw…

>With APT, you get a single version of each package, so it's all or nothing. It's definitely not used as often as in npm packages, but you can use =version after your package name to apt install a particular version, or apt pinning for more complex setups.

The point your parent is making is that with mom, you can install one version of a package per project you’re working on, instead of one version on the system. Especially if you’re working on multiple projects or multiple versions of the same project, this is required.

Re: Malicious code in the purescript NPM installer

#156

Post by scbrg »

hnbroseph wrote: post #97
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.

> I trust these people why?

Can't speak for parent, but because they have historically shown themselves to be trustworthy.

I don't know much about the "NPM community," but judging from the bits I do hear, I'm not sure they have done the same. OTOH, I understand that as an outsider that only pay attention when shit blows up, I'm only seeing the bad parts.

Re: Malicious code in the purescript NPM installer

#157

Post by trabant00 »

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.

> Packages being months behind the latest version is a feature, not a bug

I struggle to convince devs and management about this in the past few years. Everyone's gone crazy about latest and greatest set of features with no respect for stability, maintainability, etc.

Re: Malicious code in the purescript NPM installer

#158

Post by hanniabu »

jonas21 wrote: post #37
hobofan wrote: post #31

Earlier quoted context omitted.

That's not a "solution". That's just shifting the trust to a different (smaller) group of people.

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

In my opinion there should be different namespaces, similar to what the parent mentioned. There can still be the public namespace as there is now, but there can also be ones registered, such as google/mysql-golang. The other alternative is that it's just linked to Github/Gitlab, but then you run into potential naming collision issues.

Re: Malicious code in the purescript NPM installer

#159

Post by pjmlp »

soulofmischief wrote: post #144
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.

Since another user explained that point, I would also add that in the "move fast and break things" environment of the web, for better or for worse, responsive and automated library updates are often desirable or even required functionality which can be tied to substantial real-world profits if something suddenly goes wrong somewhere in the stack.

Web development is one of my tasks and thakfully we don't move fast and break things, rather rely on proven and established development stacks like JEE, Spring, ASP.NET and VanilaJS.

Re: Malicious code in the purescript NPM installer

#160

Post by pjmlp »

allover wrote: post #33
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.

> 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.
Post reply on HN