Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A trojan distributed through NPM is still a trojan. It matters not whose code it was but the intention to do harm.


is it a "trojon" when a maintainer decides to break backwards compatibility with their next release and breaks your code? how is this any different?

Did you miss the bit in the license that states, "THE SOFTWARE IS PROVIDED "AS IS"?

when you decide to incorporate code with no guarantees into your project, you get what you get. Marak is a hero in my view to the open source community. The cost of free software is that there is nobody to point a finger at. Acts like this show-case that being able to point a finger at someone is worth something. And, maybe corps that use open-source software will begin to address this "risk" and maybe this outcome will benefit the open source community.

The "AS-IS" part is a big problem and is addressed through funding. Where, exactly what IS gets negotiated for a price.


If it had deleted files, or extracted user password data and uploaded it to pastebin you would agree it's a Trojan, yes?

Your license agreement is not going to save you from the feds if you write code like that.

So we are arguing where the line is. From what I understand, having not run the code myself, he wrote code that put the system into an infinite loop, i.e. he intentionally caused a hang. That crosses the line in a clear way, for me.


Then it would be a crime in more or less any country.

Now the question is if it's hanging intentionally?(Software as-is) license only helps so much. Think the answer for this is not clear cut.

Without question a line was crossed.

I mean sure there are endless problems about how npm handles things, but it's more nounced.

Like e.g. you needing to go out of your way to lock dependencies instead of it being some form of defaultish behaviour is a problem.

People distributing CLI tools without having strict dependency locking is a even bigger problem/no-go.

And this showing how careless some people are when it comes to distributing software is probably the most interesting thing.


It wasn't backwards incompatible, it was outright designed to cause chaos. If an open source maintainer pushes an update that intentionally starts killing whatever processes it can or intentionally fills up the disk with garbage, is that not an attack? How is an update that intentionally infinite loops, printing garbage to stdout any different? There's very much someone to point a finger at: he went out of his way to cause chaos.

Does that mean corporations have no responsibility? No. But it's also the case that we live in a society and your ability to wreak havoc because you can shouldn't be empowered.


> a maintainer decides to break backwards compatibility with their next release and breaks your code?

a maintainer breaking backwards compatibility is not malicious.

The faker.js code is intended to be malicious, and thus should be treated differently to another project which might break your code in other ways. Because it's not about breaking code, it's about the maliciousness - the same would still apply if the faker.js trojan is more hidden, and thus was not discovered (e.g., they embed a crypto-miner into the library and extract compute resources secretly from those who use it).


The difference is intent. If someone makes a mistake, even if deleting all their code, that's a bug. If they intentionally make a change with no other purpose than breaking your stuff, that's an attack. The scale and whether they're successful doesn't matter.

    > attack (plural attacks)
    > An attempt to cause damage, injury to, or death of opponent or enemy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: