Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bleepingcomputer.com

Post reply on HN
Print view View original

701–710 of 1001 posts

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

#701

Post by kodemager »

bastardoperator wrote: post #108

Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…

I think it’s a bad stunt that outlines an issue with mega corps using oss and blindly updating their packages. Or anyone blindly updating their packages really.

But I don’t see how GitHub has the right to suspend him and rewind his work. I mean, that has to be a copyright infringement if there ever was one.

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

#702

Post by Too »

p2t2p wrote: post #595
pinum wrote: post #426

Earlier quoted context omitted.

>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. Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }

Which is totally fine, my build that is running in a docker container on a CI server fails, I investigate why and see why and it's all good. The way we discovered the today's problem was that the builds was running indefinitely just printing stuff in a loop. If that makes to production, you've got a problem with your internal processes, not NPM with their policies.

You realize the code above is based on runtime? Isolating the build here makes zero difference in such a time bomb.

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

#703

Post by Dracophoenix »

sertraline wrote: post #589
Sebb767 wrote: post #541

Earlier quoted context omitted.

There's a difference between stopping to give away your stuff for free and acting maliciously. If I give away donuts for free and stop at some point, you have no right to complain. If I poison the donuts because you should've really thrown money at me for those donuts that I explicitly marked as free , I think you could complain after all.

My parents always taught me not to take donuts from unknown people, especially when they're free. It's common sense and corpos take all fault for taking an easy fix to save their own developer hours at someone's else expense. Now, when it turns out there are consequences to this, corpos aren't that happy.

With that argument, you might as well say that open-source/free software shouldn't exist.

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

#704

Post by Too »

kodemager wrote: post #701
bastardoperator wrote: post #108

Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…

I think it’s a bad stunt that outlines an issue with mega corps using oss and blindly updating their packages. Or anyone blindly updating their packages really. But I don’t see how GitHub has the right to suspend him and rewind his work. I mean, that has to be a copyright infringement if there ever was one.

A stall owner who deliberately injects poison into their apples should rightfully be thrown out of the Bazaar. Regardless if the apples are given for free or not.

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

#705

Post by junon »

anonymousab wrote: post #679
junon wrote: post #550

Earlier quoted context omitted.

DMCA notices have to be complied with else Github can get heavily penalized. This isn't Github's choice. DMCA is an entirely different beast, and it's not Github's fault that whole system is broken.

> DMCA is an entirely different beast, and it's not Github's fault that whole system is broken. Microsoft and co. probably have the leverage to move that needle a little if they really wanted to.

No, they don't. Companies don't fuck around with the DMCA stuff.

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

#706

Post by pmontra »

raesene9 wrote: post #7
dagmx wrote: post #4

Earlier quoted context omitted.

GitHub ToS allow terminating accounts for malicious behaviour, which I'd argue that purposefully breaking downstream code is.

That seems like a bit of a shaky ground to stand on for GH. If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, then at a later date they change that code in a way that breaks other people's use of it, do GH then take over the account?

I happened to create an infinite loop in some of my programs but not intentionally like the author did. Furthermore he intentionally pushed the infinite loop with the result to DoS everybody knowingly or unknowingly using his software. This is malicious behavior IMHO.

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

#707

Post by yoavm »

bluefox wrote: post #496
chii wrote: post #480

Earlier quoted context omitted.

Intent matters. Windows contains the rm -rf code, but you, as a user, would have to knowingly trigger it and confirm. It's not like windows tricks you into formatting your drive. Directing the argument into windows is just whataboutism.

[flagged]

Knowingly?! Clearly every developer of an app breaking because of these packages had no idea their app is going to break, and clearly it was exactly the intention. They _were_ tricked.

Can you not see a difference between this and between releasing a new package with a README saying "this module will print 'liberty liberty liberty' to your console in an infinite loop!"?

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

#709

Post by bostik »

xg15 wrote: post #680
justinpombrio wrote: post #592

Earlier quoted context omitted.

> 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. I think it follows from two things: 1. We use open source software for everything. This is also true of our dependencies, so we get hundreds or thousands of transitive dependencies. Many of which are presumably written by dogs, because (i) no one…

Yeah I guess then we can just shrug and go on because there is nothing we can do to stop our app from randomly breaking tomorrow. > So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. But this is different from just blindly accepting any update that upstream gives you. > And also defence in depth. This sounds increasingly like security theater. You…

Defense in depth implies a whole lot of things, and is certainly not security theater. Usually it boils down to three major themes:

1. Reduce blast radius: assuming component X is compromised, how far and wide can it be felt?

2: Principle of least privilege: once compromised, what can X do or access? Extend to the credentials X carries or has access to.

3: Detection: how early and how well can you detect the compromise in previous two steps?

You can never prevent a compromise, but you can make it easier to notice when it has happened, and you can limit what the attackers can do afterwards.

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

#710

Post by rich_sasha »

apetresc wrote: post #143
cerved wrote: post #99

Earlier quoted context omitted.

look at diffs?

Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.

And frankly, not just diffs. You’d need to inspect the initial state, and any new dependency added. That’s potentially hundreds of thousands of LoC.
Post reply on HN