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

161–170 of 279 posts

Re: Malicious code in the purescript NPM installer

#161

Post by 9dev »

elliekelly wrote: post #53
orblivion wrote: post #43

Earlier quoted context omitted.

While people give reasonable counter-arguments here to your point, it gets me thinking - I wonder if we could find a truly benign form of "malicious code" that "good guys" could use to find attack vectors before the "bad guys" do. Perhaps there could be a website set up to get pinged by "malicious" installers? Perhaps it displays stats of some sort? It could turn into a friendly game.

I actually built something like this a few months ago. I called it “OSSassin” (like the game[1]) so devs could sign up & get a unique ID/url to ping with the idea that everyone participating would then try to secretly, and not maliciously, “assassinate” the packages that have agreed to participate by sneaking in code to ping their endpoint. Just as a fun/friendly game to help identify potential vulnerabilities. It ha…

If you're still up for this, publish the source on GitHub. That's an excellent idea and I'd like to participate :) @dane-pgp's suggestion of verifying the hack by checking the source repository is great too. Maybe it'd be easiest to just name the endpoints something like `/ping/github//`.

Re: Malicious code in the purescript NPM installer

#162

Post by lenkite »

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

Don't know whether to laugh or cry at this. Truth is stranger than fiction in the land of JavaScript. Could any developer 20 years ago predict this is what software engineering on the Web would devolve to ?

Re: Malicious code in the purescript NPM installer

#163

Post by varjag »

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?

There is a process for recruiting Debian devs where trustworthiness is a consideration.

https://wiki.debian.org/DebianDeveloper#Advocating_a_Debian_...

There is none for npm.

Re: Malicious code in the purescript NPM installer

#164

Post by lenkite »

dmitriid wrote: post #154
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.

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.

I fear your analogy does not go far enough if you are comparing the JS ecosystem to the UNIX philosophy.

Javascript would offer a library for every single option, variant and logical operator for a UNIX command. Combinatorial explosion will devour the web. It already destroys dev laptops anyways when downloading something via NPM.

Re: Malicious code in the purescript NPM installer

#165

Post by mschuster91 »

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…

Why not resolve the owner name to some kind of uuid at time of package require/install and saving it in the lockfile? That way, a package upgrade can detect if the owner name has changed and fetch the correct package.

Re: Malicious code in the purescript NPM installer

#166

Post by mschuster91 »

filleduchaos wrote: post #128
xeonoex wrote: post #115

Earlier quoted context omitted.

See, .NET get a lot of hate from the open source community, but this reason is one of the big ones of why I prefer it. Even when you compare it to Java, I feel like it's way better in this regard. If I want to work with JSON, I use Newtonsoft.JSON. If I want an ORM I'll use Dapper (lightweight) or Entity Framework. So many libraries that would you need if you're using Java or JS is just built in to the standard libra…

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

Re: Malicious code in the purescript NPM installer

#167

Post by soulofmischief »

pjmlp wrote: post #159
soulofmischief wrote: post #144

Earlier quoted context omitted.

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.

There are some reasonably stable packages in the npm ecosystem, it's just pretty much the Wild West out there. It really depends on what you're building. It's pretty hard to get a new SPA started these days without a development environment which uses npm, especially if you're running lean.

The problem is keeping your dependency tree reasonable. Even pulling in a couple of packages might lead to hundreds of dependencies. And even if you have the sense not to use an external package for something as simple as left-padding a string, someone somewhere in that dependency tree might not feel the same way. And that's all it takes to bring a chunk of the web down.

All of these problems of course are due to JS not having a mature ecosystem or standard library. People shouldn't need to reinvent the wheel every hour, nor should they be pulling in modules less than a dozen or two lines of code. That, and the constant misguided financial incentive to deploy ever more complex functionality over http are what lead to this aggressive push for cutting edge tools.

Re: Malicious code in the purescript NPM installer

#168

Post by GrumpyNl »

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.

You should take a look at the trim package and how often hat is downloaded.

Re: Malicious code in the purescript NPM installer

#169

Post by wdroz »

geofft wrote: post #24
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.

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.

conda use namespaces (called channels). If you want a package from a random person, you've to explicitly add it (either globally or when installing the package).

Re: Malicious code in the purescript NPM installer

#170

Post by hardwaresofton »

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…

It seems like a reasonable fix to this is to prevent name-specific owning (changing it to a group instead) -- this has the benefit that package maintainers who plan to maintain their packages forever can keep the same names, and those that don't can essentially fork their project and stop fixing the older version (@ /) and force all changes to go to a new one (@ /) and hand off ownership as necessary.

This doesn't break old consumers and it allows for a pretty graceful migration path (if you want new updates, change your version) -- can eve be helped with marking package as deprecated or repo as archived and what not.

Post reply on HN