fix: [security] Replace colors with chalk.

[jwalton]

Description

This replaces the colors library with chalk after the author of colors added an infinite loop to colors/lib/index.js as a protest.

cli-table is actually already safe, because it had colors.js pinned to an old version, but I'm doing my best to remove the author's code from popular packages because it makes it easier to audit my toolchain.

Checklist

Please make sure the items below have been covered before requesting a review:

• This change works and has been tested locally (or has an appropriate fallback).
• This change has relevant unit tests.
• This change has relevant documentation additions / updates (if applicable).

Steps to Test or Reproduce

Existing color test cases are passing.

[Andrew-Hopkins-Liqua]

+1

The maintainer of the colors package has purposely deployed a corrupted breaking change in protest of not getting funding.
This has caused cli-table to print an infinite amount of garbage output, and not work correctly.

https://snyk.io/blog/open-source-maintainer-pulls-the-plug-on-npm-packages-colors-and-faker-now-what/
Marak/colors.js#285

This issue has run-on effects with Firebase-tools (which uses cli-tables as a dependancy)
firebase/firebase-tools#3999

And with github actions firebase-hosting-deploy ( which uses firebase-tools as a dependancy )
FirebaseExtended/action-hosting-deploy#188

See image below ( garbage output from dependancy "colors" )

[korostelevm]

Why not pin the chalk version, just in case

[jwalton]

Pinning in a library is generally a bad idea (present circumstances excluded). If we pinned this to chalk 4.1.2, and a bug fix came out in 4.1.3, we’d have to merge a patch to this library and then all consumers of this library would have to upgrade this and chalk. A critical security vulnerability could take a long time to propagate its way down the dependency tree.

It also means if you have this dependency pinned at 4.1.2, and you use some other library that pins it at 4.1.1, then you needlessly end up with two copies of chalk in your node_modules.

Of course, if you’re consuming cli-table in an application, you absolutely should pin this dependency via a package-lock.json or yarn.lock.

[chrean]

I see pinning as an interim solution.
Moving to a new package requires planning and testing, and in the meanwhile pinning the dependency to a specific, non-broken version can be a good idea. I think that will be our plan here.

[nickdaugherty]

It's true that pinning can slow down deployments of fixes in scenarios like this (installed software like a CLI), but it also protects against these things just as much. As evidenced here, package maintainers can be unstable, or accounts can get compromised. If things had been fully pinned, we wouldn't be scrambling to address the issue from colors.

[jwalton]

If you have a lockfile, you’re not scrambling to fix anything related to colors. Only new installs should be affected by the mess with colors.

(As an aside, If you’re curious to know what kind of a world we’d be living in if libraries pinned all their dependencies in package.json directly, I’d invite you to have a look at this PR. Not quite this exact scenario, but this is the sort of thing we’d all be doing on a regular basis:

webpack-contrib/css-loader#472)

[leandrobudau]

Will we have the merge of this PR?
In our projects we are using the cli-table. Otherwise, we will have to change it here.
Can we proceed with this PR?

[DABH]

Hey folks -- I'm grateful the community has been proactive here :) I opened #169 which allows cli-table to stay with colors but uses the new fork which is securely maintained and updated. It may be easier to just use that PR than migrate to chalk. chalk is a somewhat heaver library and it's a bigger migration, so I would argue sticking with @colors/colors may be better, but I will leave it to the maintainers. Thanks, and please lmk if you have any questions!