carbon-charts
carbon-charts copied to clipboard
carbon-design-system
[Bug]: CVE-2021-29060 with the package `color-string`
Contact Details
No response
What happened?
There's a security vulnerability linked with color-string dependency package:
https://nvd.nist.gov/vuln/detail/CVE-2021-29060
└─┬ @carbon/[email protected]
└─┬ @carbon/[email protected]
└─┬ [email protected]
└─┬ @dabh/[email protected]
└─┬ [email protected]
└─┬ [email protected]
└── [email protected]
Version
@carbon/[email protected]
Data & options used
No response
Relevant log output
No response
Codesandbox example
No response
@stanislavgeorgiev is this coming from the @carbon/telemtry package? Seems like it
We had @jdharvey-ibm look into this. Here's what I got from him
Seems like winston hasn't released any new versions that'd remove the vulnerability.
Until then I it seems like users would need to use shrinkwrap or similar methods to make sure a newer version is installed as it seems like there isn't anything that we can do about it.
Feel free to re-open with additional comments
We certainly can and should do something about it, we can't just close this issue without resolving the vulnerability. File this same issue in their repo, once it gets resolved adopt the new version and then this issue can be closed.
Dealing with vulnerabilities is a core checkpoint at IBM when releasing new software. This issue needs to stay open until the vulnerability is resolved.
I don't have permissions to re-open, I would've done it otherwise.
As Joe mentioned, we don't ship a yarn.lock with Carbon Charts, therefore we can't easily override the versioning of nested dependencies.
This does indeed seem to be an issue with a nested dependency, which is why I think shrinkwrap could work in just pinning the versions up to a higher number.
Did you try that approach? In my experience shrinkwrap could pretty quickly fix this issue for you.
I'll re-open since you requested
To add to what @theiliad said:
The vulnerability itself has already been fixed in the color-string library. There's a long chain of node modules that are "upstream" from that module which ultimately gets to carbon-telemetry and carbon-charts (we depend on Winston, which depends on diagnostics, etc.).
By convention, none of these intermediate modules have explicit dependencies on exact versions of node modules. Instead they depend on something like colors: ^3.0.0, which means they will allow their module to work alongside any minor and patch version of colors, so long as the major version is 3. This is done for the exact reason we're seeing right now with this issue: Security fixes should automatically be able to be picked up, so long as the down-stream fixes don't break the external APIs of the package in which they are fixed.
This allows the end user of the library (you) to have control over when and how you upgrade the node modules in your project. You, as the library consumer or application developer, have the ability to upgrade your node modules, package lock file, yarn lock file, shrinkwrap file, etc. whenever you see fit. In doing so, you'll trigger the entire dependency chain to be re-analyzed. It'll look for newer module versions that are still compatible, and automatically pull them into your project without needing any of your downstream dependencies to alter their code or block your ability to fix vulnerabilities as you discover them.
The only case in which the downstream libraries would need to change would be if a vulnerable package required a major or otherwise breaking change to their package, which is not automatically covered by the acceptable version range up through the dependency chain. For example, if this vulnerability required color-string version 2, then there'd be work to do for the down-stream libraries. But even in that case, you as the end user still has the ability to resolve the issue on your own by running npm audit fix or npm audit fix --force to forcefully say that you want to pull in a newer version of a perviously vulnerable package.
Hopefully this info clears things up! I'm happy to answer any questions you have about the process.
I haven't tried this shrinkwrap because I have no experience with it.
So far npm audit fix is usually breaking things more often than fixing them as well.
I've used it before but don't exactly remember how it worked. I think you create a json file telling npm which versions to use for nested deps
Here's a quick result I found https://stackoverflow.com/a/17423915/6218230
@stanislavgeorgiev Does your project currently have a yarn.lock or package-lock.json file in it? If so, then there's no need to fiddle with shrinkwrap. For this case in particular, if npm audit fix isn't getting you what you want because it's too obtrusive, I'd recommend either npm update @carbon/charts or npm uninstall @carbon/charts && npm install @carbon/charts@some-specific-version-that-works-for-you. I would expect either of those approaches to resolve this issue for you.
Yes, we do have a package-lock.json file. I will give the npm audit fix a try next week after we upgrade to Angular 13.
Hi @stanislavgeorgiev - Is this still an issue with @carbon/[email protected]? BTW, if you are interested, there is Angular 16 support in @carbon/charts-angular@next.
@nstuyvesant This is not an issue in 1.11.8. IIRC this was fixed back in v0.55.1 If you do still see issues in this area on that version, definitely let us know.
Thanks for confirming @jdharvey-ibm. @stanislavgeorgiev - please close this issue.