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

People didn't actively go seek out a new version.

He intentionally abused semver to disguise it as a safe update, when it was not.

I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement.



It's his project. It's a free, open-source project. What does the maintainer owe us? Absolutely nothing.

> I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement.

Be thankful that all he did was spam the console. It could have been something more malicious. Updating dependencies without auditing source code is a very common practice, but that doesn't mean it's not the victim's fault. It is unrealistic to audit the insane amount of source that our projects are built on, but that is the exact tradeoff that we're making in exchange for the productivity of not building libraries ourselves or paying for those libraries.

Open source is something that we're gifted not something that we're owed. If you disagree, then feel free to either use exclusively proprietary software where you can have expectations of the maintainer, or build all of the functionality that you need by yourself.


I think that open source developers still owe us not to maliciously run malware on our machines.

To be clear they do not owe us to produce good code, or to keep producing code, or to produce the code we want; it is remarkably close to charity giving: the developer/mantainer is donating their work/code to the community.

Just like charity you should not give poisoned gifts.

The kid that gave homeless people oreos with toothpaste filling wasn't charitably offering food to someone in need, he was maliciously offering them a "poisoned" gift.


Open source developers don't owe anyone anything. It's this entitlement that has led so many of our fellow people in the community all the way to depression. Stop expecting something when it was explicitly stated that software is provided with no guarantees.


My point is different: People owe everyone not to maliciously inject malware on their machine, it is irrelevant whether you are an open source developer or not.

The author published the packages to a public registry with the expectation that the code would be run by others, it was not just a random github project, it literally invited others to run the code by being registered on npm.

The author explicitely offered no warranty on the code, but distributing malware is both illegal and against npm ToS.

Being an open source developer does not put you above ethics.

The only thing that would change this would be if some third party was mirroring their code on npm without the author consent.


If you choose to download my code and include it in your project and it doesn't do what you expect, that is on you.

The colors library has an infinite loop and you shipped that version to your end users? That's on you. Test and pin your dependencies. Not doing so is the true offense. Be upset with AWS and the likes who will run unvetted third party code on your machine.

Also note that an infinite loop is not malware. Implying such is insane. Are you now going to call every piece of crashing software malware?


People are going to include the code in question mostly via transitive dependencies. Creating an app with create-react-app will lead to at least 2000+ such dependencies. That's just how the entire npm ecosystem works, and so there is certain community wide expectations not to do this sort of thing, and when it does happen, have mechanisms in place to contain the damage. I agree that people should reassess their exposure to such a ecosystem but that is besides the point.

I believe this is akin to not driving dangerously on the road. There is obviously a social contract. This what living in a society is all about. Just because someone can do something doesn't mean we can't expect otherwise.

His work benefited from the work of many other people who also released open source software. That not only includes the packages that he released, of which he had other contributors, some of which actually wrote more of the package than he did (colors.js) as well as packages that he more or less did a direct port from (faker.rb and CPAN::faker). He also benefited from the entire npm/node ecosystem.

People have every right to be pissed.


> If you choose to download my code and include it in your project and it doesn't do what you expect, that is on you.

Completely agree.

But the key concept that keep avoing is malicious intent.

Let's make an analogy in a completely different topic: Are (D)DoS attacks wrong? do people owe us not to (D)Dos our machines?

On one hand we connected our machines to the internet and declared ourself as ready to accept incoming traffic; on the other hand spinning up a bot army to render said machines unsusable is not nice.

Is it correct to say that you should have some kind of (D)DoS pretection on your services? yes. Is it also correct to say that people should refrain from crapping on other people stuff? also yes.

Getting back on topic; there is possibly a solid case to argue that this was not criminal (as no unauthorized "access" happened) but as much as open source volunteers should be more appreciated the "don't intentionally damage stuff with the SOLE intent of damaging stuff" is something expected of any human regardless of their social position.


> Are (D)DoS attacks wrong?

Yes, if you attack infrastructure that you do not have permission to test. Here people downloaded code, ran it on their own infrastructure (or worse: shipped it to their users!) and were surprised this code did not do what they expected.

So, the only malicious actors here are those who shipped the package to their end users. Not the developer, they did not ship the code to anyone. They simply released a new version that other people chose to download and include in their own work.

To be clear, it's a total dick move and I don't support it at all, but the real blame should go to those who blindly download such code and run or redistribute it.


I totally agree.

We need better tools to prevent things like this from happening again because nobody is ever going to audit the 2000 dependencies of every new create-react-app release.


> I think that open source developers still owe us not to maliciously run malware on our machines.

The open source developer didn't run anything on your machine. You ran it on your machine. The developer published code. Others blindly pulled the update, and that propagated.


> Be thankful that all he did was spam the console.

Why would I be thankful for that?

If you slap me, should I be thankful that my nose wasn't broken?


If nothing else, he illustrated a point that many people needed made. They got off cheap - he didn't exfiltrate data, install malware or whatever. He showed that their supply chain is insecure, and that they are trusting way too much in the kindness of unpaid strangers.

If your business or development practices depend on pulling a bunch of packages from NPM or other sources un-audited and so forth - especially straight into production! - you need to seriously rethink things. You got off relatively light, this time, if you were impacted by this.


Fool me once… etc.


> People didn't actively go seek out a new version.

When they set their dependency versions to 'latest', that's exactly what they are doing.


however, I think the more common case is that they set it to the latest bounded by a minor or patch version (as opposed to a major version) as defined by semvar.

at least that seems to be quite common in the npm/js world.


> People didn't actively go seek out a new version.

They did. They chose not to pin their dependency versions, so this is their clear explicit choice. They also chose not to test their dependency updates before pushing it through to their end users, pure negligence by e.g. AWS who was affected by this.


> People didn't actively go seek out a new version.

Yes, they did. Have you read the article ? That's how npm works: it always pulls the latest version.

You can't use tools you don't understand and blame someone else if it doesn't work as you expect it to.


> Yes, they did. Have you read the article ? That's how npm works: it always pulls the latest version.

No, it pulls the specified version.

The affected packages fixed it by removing the leading carpet in the version specifier, which was designed to allow patch version bumps for things like security fixes.

He literally abused the versioning system designed to allow security fixes by introducing a breakage and disguising it as a non-breaking change.




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

Search: