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

471–480 of 1001 posts

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

#471

Post by junon »

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.

> pulls the release then you're not getting access to your dependencies at all.

NPM no longer allows this.

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

#472

Post by dimgl »

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

I love Chalk! I didn't realize it came after colors. Thanks for maintaining this package.

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

#473

Post by Diggsey »

josephcsible wrote: post #246
joshuaissac wrote: post #117

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

People who are upset that GitHub suspended him: would you still be upset if the contents of the new package were "require('child_process').exec('rm -rf /*');"? If not, then how malicious does code have to be before a suspension is okay in your opinion?

Just because there might be a grey area in some cases, doesn't mean that you can't also distinguish some cases. Your example is clearly much more malicious than what the package author actually did.

This is obvious from the fact that GitHub won't suspend your account for releasing a new version of a package that has breaking changes... Clearly there is a scale here. The only disagreement is about where the line is.

IMO, if the package author had simply deleted the code - ie. published a new version with no functionality, then no action should be taken against them by GitHub or NPM. For this example, I think suspending the account is OTT, but I think NPM would be justified in reverting the package, since an infinite loop is somewhat malicious: and by that I mean that nobody would reasonably expect a package to hang just from importing it. If the package actually deleted data, then both the suspension and NPM revert would be justified.

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

#474

Post by junon »

TranquilMarmot wrote: post #239
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.

The little `^` in version numbers in NPM's `package.json` file is such a bizarre choice. The fact that it by default installs all new dependencies with that means that builds on different machines at different times could result in _completely_ different artifacts.

I use an .npmrc in all of my repos that turns this off. It doesn't help nested dependencies but at least it reduces some of the headache.

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

#475

Post by can16358p »

pinum wrote: post #426
brundolf wrote: post #383

Earlier quoted context omitted.

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 mac…

>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 on other dependencies.

Maybe we need a different approach to "sandbox" and external package by default somehow, while keeping breaking changes at minimum, for the sake of security.

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

#476

Post by feupan »

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?

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

#477

Post by arvinsim »

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.

I am still frustrated that npm install defaults to `^1.0.0` installations instead of exact `1.0.0` versions.

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

#478

Post by galaxyLogic »

cjonas wrote: post #235
pc86 wrote: 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…

You can pin the direct dependency, but what if the packages you depend on don't pin their own dependencies? The standard (default behavior) is to use ^, which will automatically install new minor versions. Package.lock helps, but there's no sane way manage upgrades. Just running "npm audit fix" could result in pulling down a bad package.

If you pin your direct dependency doesn't that mean it can not change versions of its dependencies?

The same version number of a package should always link to the same version numbers of both its direct and nested dependencies. No?

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

#479

Post by harikb »

I have a related question on how developers should sandbox their dev work from other uses of their computer (banking, email etc). Even though one might vet/vendor dependencies, these (say pining a version) are done closer to production/testing. Developers might be more relaxed updating to newer version for the purpose of vetting them.

I am glad VsCode pops up a warning on all new repos - but that kind of warning will often end up getting dismissed because it occurs all too often.

Should all dev work happen in VMs? Docker?

Where is the web-of-trust solution for dependencies?

Where is the notary service for dependencies?

This all feels like a ticking bomb to me.

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

#480

Post by chii »

bluefox wrote: post #347
josephcsible wrote: post #246

Earlier quoted context omitted.

People who are upset that GitHub suspended him: would you still be upset if the contents of the new package were "require('child_process').exec('rm -rf /*');"? If not, then how malicious does code have to be before a suspension is okay in your opinion?

I take it you've never read a virus magazine like, say, 40Hex or 29A? What is "malicious code" anyway? Maybe Microsoft Windows is malicious. It does contain code to format your disk.

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.

Post reply on HN