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

#531

Post by ihumanable » Mon, Jan 10, 2022, 3:17 AM UTC

throwthere wrote: post #380

NKosmatos wrote: post #114

Try to look at it from another point of view. Marak is fed up of all these billion dollar companies (and other small projects) using his code, he has some financial problems and so he decides to teach them a lesson. I sympathize and for sure if I were responsible for a big company and I was using an open source component/project I would donate something. We all have to rethink of how the open source funding is suppos…

faker and colors aren’t exactly high value libraries. They’re widely used but only because they’re easy to import and free. I think that’s part of the problem.

I concur.

The author of the packages wants to use the fact that there are so many downloads to justify their position that they should pay him. The only reason the downloads exist was because he gave it away free.

If the author had started by charging a license fee, they would have close to 0 downloads. Someone else would have made a library to wrap strings in ansi-escape characters and pull random values out of data packages assembled by the Perl community.

The author does seem to be having some sort of mental health crisis at the moment. I hope they get the help they need.

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

#532

Post by pessimizer » Mon, Jan 10, 2022, 3:18 AM UTC

Osmose wrote: post #352

josephcsible wrote: post #338

Earlier quoted context omitted.

> In theory, this was enforced by copyleft requiring derivative works to also be free software. In practice, companies use software with permissible licenses instead because then they can reap the benefits without any requirement to pay it forward. If you want to fix this, stop contributing to permissively-licensed software. If you have a change you want to make, make or find a GPL fork of it and contribute it to tha…

Individual action is not gonna solve anything, you have to understand why people choose permissive licenses in the first place: - They're contributing while at work and work only allows permissive licenses - They're familiar with permissive libraries because of the previous point - Permissive licenses are perceived as simpler - They've been pushed away from the free software movement by the FSF/Stallman/Linus - They…

I don't think anyone is confused about why people prefer permissive licenses. People enjoy benefits without costs or responsibilities, unsurprisingly.

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

#533

Post by akersten » Mon, Jan 10, 2022, 3:18 AM UTC

betwixthewires wrote: post #501

not2b wrote: post #424

Earlier quoted context omitted.

That doesn't give him the right to commit sabotage. If as the developer of a FOSS program I deliberately introduce something that will harm users, a "no warranty" clause won't protect me from the consequences. The guy knew full well how npm worked, and new full well that he was deliberately breaking lots of sites. "No warranty" just means he isn't liable for accidents.

No warranty means he isn't liable for any behavior of the software at all. You don't have to like it but it is true.

Of all the awful legal takes I've seen on this site, yours is an early contender for best of 2022.

> No warranty means he isn't liable for any behavior of the software at all.

Somebody should tell all those computer virus authors, all they had to do was not include a warranty, and they're untouchable!

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

#534

Post by junon » Mon, Jan 10, 2022, 3:20 AM UTC

feupan wrote: post #476

junon wrote: post #455

Maintainer of Chalk[0][1] here, a very popular alternative to colors. Happy to help anyone that would like to port away from colors to chalk, or who might just have general questions about terminal colors. Just reply here and I'll see them. [0] https://GitHub.com/chalk/chalk [1] https://npmjs.org/package/chalk

Is a codemod available for anyone who wants to migrate?

Not at the moment, but the migration should be pretty straightforward if you don't use the more elaborate color functions from `colors` (e.g. we don't have things like "zebra").

If you use `require('colors/safe')` and only use the basic colors, then Chalk is more or less a drop-in replacement.

If you use the property values (e.g. `"my string".green`) then you'll need to change that to `chalk.green("my string")`.

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

#535

Post by jeffparsons » Mon, Jan 10, 2022, 3:22 AM UTC

can16358p wrote: post #475

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 ~") }

Moreover, anyone who either has malice intentions (or depend on other packages, of whom authors do) can make the whole process much less noticeable with relying on variables from URLs that get executed, which may themselves be linked to other dynamic dependencies, creating all sorts of logic/time bomb or RCE attacks. That kind of behavior would be practically impossible to code-review for lots of packages that rely o…

This is what the folks working on WASM/WASI and related projects are trying to achieve.

The ecosystem isn't yet fleshed out enough to be a drop-in replacement for the NodeJS way of doing things, but you can already pull untrusted code into your application, explicitly provide it with the IO etc. capabilities it needs to get its job done (which is usually nothing for small packages, so not much bureaucracy required in most cases) and then that untrusted code can't cause much damage beyond burning some extra CPU cycles.

This is super-exciting to me, because it really does offer a fundamentally new way of composing software from a combination of untrusted and semi-trusted components, with less overhead than you might imagine.

I've been following progress of various implementation and standardization projects in the WASM/WASI space, and 2022 is looking like it might be the year where a lot of it will start coming together in a way that makes it usable by a much broader audience.

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

#536

Post by jdavis703 » Mon, Jan 10, 2022, 3:22 AM UTC

Is there any project or organization that forks non-corporate packages and verifies updates? Rouge developers and hackers will continue to be a problem. If such a project doesn’t exist, would you use it? And ultimately would you pay for it?

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

#537

Post by deathanatos » Mon, Jan 10, 2022, 3:23 AM UTC

cerved wrote: post #99

rich_sasha wrote: post #35

Earlier quoted context omitted.

In practical terms, can they really be audited? This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.

look at diffs?

I actually do this, on occasion. (Not 100%, and not to a degree I'd say "yeah, I'd've caught this colors/fakers thing." But enough to say that I've seen a decent sample.)

There is literally, on average, no difference in average quality between commits on FOSS projects, and commits on projects we pay external entities for. Some paid projects are just crap code, and some FOSS code is extremely high quality.

I've had to roll-back / hard-pin dependencies from both low-quality FOSS & low-quality paid projects because of commits that — once you find & read them — are just bananas.

(I have no idea how to solve the root problem here, honestly.)

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

#538

Post by kristjansson » Mon, Jan 10, 2022, 3:24 AM UTC

laurowyn wrote: post #79

ruuda wrote: 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 you want, if the repo/vendor/maintainer pulls the release then you're not getting access to your dependencies at all. If anything, this is the reason you use pull-through proxies. Your proxy will hold the version you depend on, regardless of upstream drama. Keep your proxy backed up and you'll be able to use those dependencies until the end of time, or you finally decide to migrate to an alternative.

Which is why you pull through a private mirror that doesn’t respect delete?

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

#539

Post by jamesfinlayson » Mon, Jan 10, 2022, 3:24 AM UTC

hsbauauvhabzb wrote: post #367

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…

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.

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

#540

Post by pessimizer » Mon, Jan 10, 2022, 3:25 AM UTC

AmericanChopper wrote: post #481

Osmose wrote: post #322

Earlier quoted context omitted.

> The FOSS way should be to pay it forward, to contribute to projects where you can. In theory, this was enforced by copyleft requiring derivative works to also be free software. In practice, companies use software with permissible licenses instead because then they can reap the benefits without any requirement to pay it forward. > If you’re expecting to get paid for it, it’s not FOSS. Being paid for your time has no…

Copyleft software isn’t free, it comes with a very hefty price tag. You don’t pay it forward by handing over all your IP. You pay it forward by contributing back. I have no moral qualms about using OSS in any project I’m working on, commercial or otherwise. Because I have published my own libraries for anybody to use, and contributed a huge amount of PRs to the software I use. When you publish something with a permis…

Working on someone's software that they make no money from isn't "paying" it forward or in any direction.

> it stops being yours, but you benefit from having a huge number of people improve it for you

It stops being yours, but somehow everyone who works on it can say they're helping you. This isn't fair. You don't have to pay for it, but fixing and adding features to the software that you use to make a living can't be counted as charity work.