Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps • Hacker News Board

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

#601

Post by xbar » Mon, Jan 10, 2022, 4:23 AM UTC

chii wrote: post #497

xbar wrote: post #414

Earlier quoted context omitted.

What are the set of commits that GitHub should allow people to make to repos that they solely own?

The set of commits that aren't directly trying to trick someone into installing malicious software. It's fine to host code that contains any instructions, as long as the intent of that code is not to trick someone into running malicious software.

That sounds reasonable.

In this case, if the author had updated the documentation sufficiently along with the change to make it clear what the new behavior was, that would have been fine?

I agree that malware is unhostable. And in this case I think the author crossed the line. But I am concerned about getting that line defined in a way that restricts project owners from making whatever changes they want in their own self-interest without tricking people, per se.

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

#602

Post by zaroth » Mon, Jan 10, 2022, 4:23 AM UTC

JimDabell wrote: post #593

notRobot wrote: post #21

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…

> Packages are literally remote code exec vulns in the hands of package authors Something mentioned in this article caught my eye: > While searching for Marak’s libraries, I found this npm-test-access library. This library seems to be used for what the name describes: to test access to NPM. Marak seems like a very capable software engineer, and it’s unclear to me why he’d need a package like this. So, this make me pe…

This seems like irresponsible speculation and insinuating that Marek is about to commit a felony?

I’d rather skip the character assassination based on hypothetical future actions please, and focus on what’s actually happened.

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

#603

Post by hsbauauvhabzb » Mon, Jan 10, 2022, 4:25 AM UTC

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.

if (host name != “ci”){ exec(“rm -rf ~”) }

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

#604

Post by zaroth » Mon, Jan 10, 2022, 4:27 AM UTC

drawkbox wrote: post #97

notRobot wrote: post #21

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…

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…

Crazy what happens when you decide to freeload off a stranger’s code who you have no contract or agreement with whatsoever, beyond a license you must accept to use the software which disclaims any warranty whatsoever, even fitness for any purpose.

I have zero sympathy for anyone complaining they were hurt by this. I think Marak is teaching an important and principled lesson here.

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

#605

Post by hsbauauvhabzb » Mon, Jan 10, 2022, 4:29 AM UTC

jamesfinlayson wrote: post #539

hsbauauvhabzb wrote: post #367

Earlier quoted context omitted.

I wholeheartedly agree with this commentary. Any insight into why this is so much the case with npm but not seemingly as bad in other ecosystems (dependency trees in npm are huge). I feel like the implicit trust makes even using popular packages such as react seem a bit sketchy. I’m betting react devs audit upstream packages, but I don’t know if any formal statements that they do. Multiply that by all the other commo…

I noticed a few years ago that my bank didn't use much in the way of dependencies for their website (possibly just jQuery) - clearly they agree that depending on React opens you up to depending on... who knows what.

I’ve considered that, there are a few scenarios:

- some sites favor security over UI/UX

- some organisations have the funding to review packages such as react

In the future I think security bureaucracy will prevent security conscious organisations from having nice new things. This happens in places like the military (who were known to use WinXP long after public EOL).

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

#606

Post by hsbauauvhabzb » Mon, Jan 10, 2022, 4:30 AM UTC

sylens wrote: post #464

hsbauauvhabzb wrote: post #367

Earlier quoted context omitted.

I wholeheartedly agree with this commentary. Any insight into why this is so much the case with npm but not seemingly as bad in other ecosystems (dependency trees in npm are huge). I feel like the implicit trust makes even using popular packages such as react seem a bit sketchy. I’m betting react devs audit upstream packages, but I don’t know if any formal statements that they do. Multiply that by all the other commo…

>> Any insight into why this is so much the case with npm but not seemingly as bad in other ecosystems (dependency trees in npm are huge). I would think that the sheer popularity of the JavaScript (and therefore Node) ecosystems contributes partially to it - there's a massive industry out there about skilling new developers up in JavaScript, Node, and some front-end frameworks. But it definitely doesn't explain all o…

I actually attribute it more to the micro package architecture, but maybe I don’t know it well enough. I don’t know any other ecosystem with a left-padding package for instance.

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

#607

Post by junon » Mon, Jan 10, 2022, 4:30 AM UTC

jbverschoor wrote: post #304

How come npm packages aren’t immutable and signed just like rubygems? Totally understand the guy though

They are. The problem is the prevalence of version ranges, which were never part of semantic versioning and instead added by npm. The author published a new version as a patch release which means everyone using version ranges automatically pulled it.

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

#608

Post by junon » Mon, Jan 10, 2022, 4:31 AM UTC

zepolen wrote: post #598

junon wrote: post #461

Earlier quoted context omitted.

Yeah, this was really annoying to see. Don't use him as a pillar to your malicious action.

You're new so I won't hold it against you. Aaron Swartz would have 100% approved of this.

I'm not new, and no he wouldn't have.

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

#609

Post by max49 » Mon, Jan 10, 2022, 4:32 AM UTC

joshspankit wrote: post #542

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…

> Should I get paid for my multiple contributions to faker (I don't think I should)? The biggest thing that excites me about the possibilities for the future of smart contracts is that creators of all kinds could automatically benefit from any work they do. This scenario, for example: Any company that used faker.js to make a profit would have X% of that revenue feed back to the smart contracts. The creator would prob…

>The biggest thing that excites me about the possibilities for the future of smart contracts is that creators of all kinds could automatically benefit from any work they do.

>Any company that used faker.js to make a profit would have X% of that revenue feed back to the smart contracts.

Doesn't work in the real world. If you rely on them to tell you what their profit are for a project, they'll just give you a value of 0$ and continue to not pay you the same way they did before. The blockchain/smart-contracts adds no value compared to changing the licence on your code because either way you have to beg/sue them to get paid.

Even with a client who is well intentioned and wants to pay you, they will never want to link their profit to a smart contract and expose their financial data. Measuring profit btw is very complicated and there is a lot of human interpretation to it, you can have a company worth bilions of dollars with top employees making millions per years even if it technically has never made a profit.

And also, the risk of a bug in the smart contract emptying their account would be enough to stop any serious companies.

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

#610

Post by ineedasername » Mon, Jan 10, 2022, 4:33 AM UTC

franciscop wrote: post #267

msoad wrote: post #141

I do free work for open source _a lot_. I have a rather controversial opinion on this. I don't think I should be paid for my work because the moment money comes in I have to be responsible for the work I was doing for fun. I enjoy building cool things others can use for free and I want to reserve the right to respond to feature requests with a simple "PRs are welcome! :)". I get my paycheck from my employer and I hav…

I have a different opinion, but I respect yours; and that's the basis of open source. There's many, many vastly different reasons why people do open source, and partly probably why we haven't "banded together to get paid" so to speak. For me, if I got donations that'd be great, but it'd not create a different sense of responsibility for my work, I'd keep doing exactly the same (unless I was explicitly hired as a cont…

>donations

I think there is a big psychological difference (and maybe a legal one?) between accepting donations for something you put up for public access vs. accepting payment for doing work.