Live data from Hacker News

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

381–390 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#381

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…

the whole point of the internet

> are literally remote code exec vulns

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#382
post #277

Earlier quoted context omitted.

This is scary, and I don’t know why people here aren’t losing their minds. I think someone should make a big deal about this. What would be the first step? On the other hand, my GitHub was once suspended (and all repos shuttered) for posting gists that looked like spam to some algorithm. It was extremely unsettling, and they need to do a better job communicating. But they may have suspended the account because they t…

Why is that scary? If you do bad things, you're going to get banned. This guy abused Github to distribute malicious code to thousands of projects. If losing your Github means losing your projects, that's on you for being lazy/irresponsible with them. Git is already decentralized, and anything important should be cloned on something you own.

> This guy abused Github to distribute malicious code to thousands of projects.

He could've done far, far worse in terms of the technical impact of these changes. It's obvious that he was trying to make a statement, not exfiltrate data to sell on the dark web.

It's scary because, as a FOSS maintainer, your code is your responsibility to do with what you will until it's no longer in the market's interest. You don't have the right to expect any sort of compensation for it, but if your project somehow becomes successful and you upset the natural order, all of the work you were told belongs to you that you should be grateful is so successful without being compensated for is now no longer under your control. There was never a business relationship to sever in the first place.

The market doesn't want to come up with a way to compensate FOSS developers with high-profile projects like these, yet the general expectation is those individuals should just continue working on these libraries for companies to profit off of them.

I wouldn't have handled this situation the way this person did, but we're reaching this point where legitimate protest and speech is being met with erasure and confiscation of your work, and that should scare everybody.

> This guy abused Github to distribute malicious code to thousands of projects.

That's one way to look at it. An alternative view is that a bunch of companies took some free code and shoved it into their apps and then got mad that the free code is causing them problems. Instead of examining the inherent contradictions of the FOSS community, commercial interests would rather just erase the protestor.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#383

Earlier quoted context omitted.

> At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] That hasn’t been true for 7 years now, it was changed after the left-pad incident and that article everyone keeps quoting is from 2016. Deleting a GitHub repo or a package does not remove it from npm as part of their p…

Does updating it with junk take any longer?

Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#384

Earlier quoted context omitted.

I don't know where people get these crazy numbers - Even in America outside of the coasts and outside of FAANG, making $140-$150+ as a senior developer is very good (and compared to almost all other industries is absurd) - salary.com which doesn't just rely on self-reported info as levels does reports the median salary + bonus for senior software engineers as $120k https://www.salary.com/tools/salary-calculator/senio…

They were using extreme numbers to say that even then you barely hit 10x. That's why the number they used for a living wage is so low too.

I just don’t think HN is interested in this anymore. There was a time. It’s gone now.

Dumb comments saying software engineers make 100x a living wage (as if this would be a bad thing) are the flavor du jour. It’s hard not to respond in kind.

But thank you, for what it’s worth. I remember you from 2010. It was quite a time.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#385
post #47

This is why you pin all dependencies and upgrade (and test) when it's convenient for _you_, not when the author pushes a new version.

> pin all dependencies You do that. Your coworkers don't. And they'll complain to your boss if you try to make them.

> Your coworkers don't.

And their PRs aren't merged until they do, because we'd have talked about it before hand and achieved consent around the idea that pinning dependencies is a practice our team will start doing, or some other specific practice that solves this problem.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#386
post #257

Earlier quoted context omitted.

It still doesn't mean you can't call the guy out for being an asshole. However, that's the only relief you'll get in matters such as these. Other avenues would be to tweet about it and make it known that this is what you can expect from the same guy in the future so avoid him for future work as he won't be acting like an adult.

That also does not mean you cant call out the corporations that are leaching off open source... I find it ironic that people are more upset at this guy for complaining about corporations, than they are about the corporations leaching... the dev and hacker communities have really gone full on #HailCorporate haven't they. Where did my anti-establishment Libre community of the 90's go... I long for the good old days

Watching people piss into the wind is fun until you get some on your shoes.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#387

Earlier quoted context omitted.

> If NPM gets a DMCA takedown request they will absolutely have to fulfill it. Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown? I suppose a developer could include the lyrics to a pop song in their code (possibly encrypted), and then tell the copyright holder about it (since I don't think you can make a DMCA request on behalf of a copyright holder withou…

> I don't think you can make a DMCA request on behalf of a copyright holder without their permission In theory, you're right. In practice, there's never any actual consequences for filing a false DMCA claim. Worst case is that the thing doesn't get taken down, but that's no worse than if they didn't file it at all.

Corps don’t care about DMCA takedowns from natural persons. I sent a takedown once, the CEO replied that he was sorry it had come to that, but they still distributed it for years under a license I did not grant. This CEO is licensed to practice law in California, btw.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#388
post #221
post #179

Earlier quoted context omitted.

Are these really RCE vulnerabilities? Looking at it systematically I only see this as an RCE vector if you're doing one or more things very wrong. This assumes that packages are immutable and an author can't update a version that's already there. This is how NuGet works, and IMO is how any remotely sane package manager will work. There's no reason for a version to be mutable in this context. Pegging to a specific ver…

The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether…

> it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version

Note that if you have a package-lock.json (which you will by default), it will prevent any surprise updates even within the semver range specified. You have to manually run `npm update` to get the latest versions that match your semver. Personally I think this is the best middle-ground.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#389
The comparison to log4j really rubs me the wrong way. The log4j developers made a poor design decision, but they were doing work in good faith in an effort to meet a user request. It was a mistake, but an honest one.

This is someone being a shit deliberately. They shouldn't be mentioned in the same article.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#390
post #153

Earlier quoted context omitted.

Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war. Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to…

How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.

> only updating if you know what the update contains

People suck at this. What this actually tends to do is mean "no updates, ever" unless you have a particularly rigorous culture of dependency management.

Post reply on HN