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

201–210 of 279 posts

Re: Malicious code in the purescript NPM installer

#201

Post by akerl_ »

hardwaresofton wrote: post #200
akerl_ wrote: post #196

Earlier quoted context omitted.

I wasn’t implying you claimed that all gems needed a group, I was proposing it as part of the thought experiment. My apologies if that was unclear. To your list of examples: my point parallels your own, I think. I’m saying that given the “right” version is arbitrary and subjective, the difference between “group-b/purescript” and “purescript-group-b” is effectively nil. More concretely: if namespacing existed, you cou…

> I wasn’t implying you claimed that all gems needed a group, I was proposing it as part of the thought experiment. My apologies if that was unclear. My apologies I certainly misread your comment. > To your list of examples: my point parallels your own, I think. I’m saying that given the “right” version is arbitrary and subjective, the difference between “group-b/purescript” and “purescript-group-b” is effectively ni…

For clarity, I think the comment referencing “go.mod” that you’re describing, at least in this thread, is from me :D

I think I agree that the core feature that impacts this issue is what go.mod solves, and what you’re describing: it should be easy and language-supported to sub in one fork of a dependency for another fork, so that users can flip between “group-a”’s purescript and “group-b”’s purescript, regardless of how the namespacing works on the module registry (notably, golang dispenses with a registry entirely: there’s no central system, except insofar as github is used for lots of people’s packages).

Re: Malicious code in the purescript NPM installer

#202

Post by allover »

McGlockenshire wrote: post #13
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…

Even PHP gets this right. It's not hard. It makes me wonder why npm hasn't already moved to namespaced package names.

> 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 namespaced package names, the problem is that it was introduced later, so isn't mandatory. I'm not sure how they could make it mandatory without breaking everyone?

[1] https://github.com/pypa/pip/issues/988

Re: Malicious code in the purescript NPM installer

#203

Post by eitland »

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…

Interesting! I thibk this is a good start but I guess it would still need some thought to be resistant to sybil attacks.

BTW: I used to think the dependencies that came as part of for example the official Angular packages where vetted.

Can anyone confirm or deny this?

Anyone can

Re: Malicious code in the purescript NPM installer

#204

Post by JulianMorrison »

Operyl wrote: post #47
JulianMorrison wrote: post #9

Earlier quoted context omitted.

2FA would also make it much harder to use the "somebody hacked me" defense.

No at that point they'd be saying "zomg NPM has a terrible bug that allowed the hacker to bypass my 2FA!" If someone is trying to redirect blame they'll always find some way to do so.

The problem is not liars, the problem is being unable to prove they were lying. With 2FA, the logs would prove it.

Re: Malicious code in the purescript NPM installer

#205

Post by twic »

geofft wrote: post #38
twic wrote: post #35

Earlier quoted context omitted.

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.

Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages and reinventing the wheel, I'm not sure what words mean anymore.

> Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages

If you've only looked at two or three languages that not coincidentally happen to do things pretty much the same as each other, and not looked elsewhere, then you are indeed disregarding other languages.

> and reinventing the wheel

I didn't mention reinventing the wheel.

> I'm not sure what words mean anymore.

Agreed, but i'm not sure i can help you with that.

Re: Malicious code in the purescript NPM installer

#206

Post by twic »

kibwen wrote: post #59
twic wrote: post #35

Earlier quoted context omitted.

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.

Namespaces would be a feature of Crates.io, not Cargo (and Crates.io was not contracted to Yehuda Katz, as Cargo was).

How so? Do you mean that Cargo would support crates with names like "example/foo" or "org.example/foo", but that's just not how Crates.io works?

If so, that's interesting, but then my question is why we didn't make use of that.

Re: Malicious code in the purescript NPM installer

#207

Post by twic »

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…

> 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] https://www.infoq.com/news/2019/05/end-of-javax-package/

Re: Malicious code in the purescript NPM installer

#208

Post by ddalex »

TeMPOraL wrote: post #119
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...

And this one-liner library even has a dependency (!) used by the surrounding error-checking code.

What's the difference between an NPM dependency chain and a black hole?

We can measure the depth of a black hole.

Re: Malicious code in the purescript NPM installer

#209

Post by tuananh »

hu3 wrote: post #191
fock wrote: post #187

Earlier quoted context omitted.

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

A dependency for /^#!(.*)/; With 8.6 mil downloads and 71 dependents... https://www.npmjs.com/package/shebang-regex

sindresorhus is famous for that stuff :D

Re: Malicious code in the purescript NPM installer

#210

Post by littlestymaar »

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 should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`.

And how is a user supposed to make the difference between @legit_dev/package_name and something like @nlegit_dev/package ?

Namespacing makes name-squatting way easier, not harder.

Post reply on HN