Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: [security] Replace colors with chalk. #166

Open
wants to merge 1 commit into
base: v0.4.0
Choose a base branch
from
Open

fix: [security] Replace colors with chalk. #166

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ your node.js scripts.

- Customizable characters that constitute the table.
- Color/background styling in the header through
[colors.js](http://github.com/marak/colors.js)
[chalk](https://github.com/chalk/chalk)
- Column width customization
- Text truncation based on predefined widths
- Text alignment (left, right, center)
Expand All @@ -19,7 +19,7 @@ your node.js scripts.

## Installation

```bash
```bash
npm install cli-table
```

Expand Down Expand Up @@ -166,7 +166,7 @@ $ make test

[![huntr](https://cdn.huntr.dev/huntr_security_badge_mono.svg)](https://huntr.dev)

## License
## License

(The MIT License)

Expand Down
4 changes: 2 additions & 2 deletions lib/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
* Module dependencies.
*/

var colors = require('colors/safe')
var chalk = require('chalk')
, utils = require('./utils')
, repeat = utils.repeat
, truncate = utils.truncate
Expand Down Expand Up @@ -230,7 +230,7 @@ Table.prototype.toString = function (){
if (!subject)
return '';
styles.forEach(function(style) {
subject = colors[style](subject);
subject = chalk[style](subject);
});
return subject;
};
Expand Down
2 changes: 1 addition & 1 deletion lib/utils.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ function options(defaults, opts) {
exports.options = options;

//
// For consideration of terminal "color" programs like colors.js,
// For consideration of terminal "color" programs like chalk,
// which can add ANSI escape color codes to strings,
// we destyle the ANSI color escape codes for padding calculations.
//
Expand Down
119 changes: 107 additions & 12 deletions package-lock.json
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@
},
"keywords": ["cli", "colors", "table"],
"dependencies": {
"colors": "1.0.3"
"chalk": "^4.1.2"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not pin the chalk version, just in case

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@nickdaugherty nickdaugherty Jan 10, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

},
"devDependencies": {
"expresso": "~0.9",
Expand Down