Duplicate packages detected in the ansicolors project on Tag: 4.1.1

[mahirkabir]

Issue: We say a project has duplicated dependencies if any package dependency occurs multiple times in the dependency tree. After analyzing the dependency tree, we have detected duplicate packages in your project.
ansi-colors
object.assign
supports-color
string-width
strip-ansi
ansi-regex

Questions: We are conducting a research study on the duplicated package dependencies in JS projects. We were curious:

1. Will you remove the duplicates mentioned above? (Yes/No), and why?:
2. Do you have any additional comments? (If so, please write it down):

For any publication or research report based on this study, we will share all responses from developers in an anonymous way. Both your projects and personal information will be kept confidential.

Rationale: When a JS application depends on too many packages or on multiple versions of the same package, its attack surface can grow dramatically; hackers can get a higher chance of successfully exploiting the vulnerabilities inside those packages (or versions), and escalating the potential damage. The unnecessary and duplicated dependencies can also make JS projects bloat and lead to extra memory/computation overhead. Therefore, JS application developers are recommended to remove unused and duplicated packages from their projects, in order to eliminate the security risks unnecessarily incurred by those dependencies.

Steps to reproduce:

• Execute the “npm ls --all” command to print the dependency tree of the project containing all the libraries and their corresponding versions
• Check if any library exists more than once in the tree

Suggested Solution: Execute the “npm dedupe” command to reduce the number of duplicate packages, or to manually modify package.json files

Resource:
https://docs.npmjs.com/cli/v7/commands/npm-dedupe

[jonschlinkert]

I don't think your issue has any relevance to this package, but I'll answer anyway since I care about the topic.

We are conducting a research study on the duplicated package dependencies in JS projects

• Who is "we"?
• Where will the "research" be published?
• What are the qualifications of the researchers?
• What is the specific criteria you're using to evaluate packages?
• Where are the "proofs" of your assertions?

We say a project has duplicated dependencies if any package dependency occurs multiple times in the dependency tree

You can update your criteria to the following: A project is duplicated when identical packages with identical versions exist.

Package managers automatically handle this, and builds can be configured to handle advanced de-duping via strategies like tree shaking, or even handling some version mismatches. If you see identical duplicate packages and you don't understand why, you can learn more about this on Stack Overflow, or create an issue with NPM or yarn to let them know that they are not de-duplicating packages correctly.

When a JS application depends on too many packages or on multiple versions of the same package, its attack surface can grow dramatically;

Please show the research that explains how the "attack surface" grows from duplicate packages, so that we can act on that information accordingly. For example, let's say there is a potential ReDoS vulnerability. How do "hackers get a higher chance of successfully exploiting packages" when the same package appears multiple times? Mathematically this makes no sense as the attack "surface" will most likely stay the same no matter how many times the package exist.

Attack "surface" is not the same as attack "vectors". Attack surface is a throwaway term that sounds scary but it's a vague, generalized, non-quantifiable colloquialism. Attack vectors are more relevant. I'd need examples of when duplicate packages create additional attack vectors. I can't see how they would in general, but there might be specific scenarios when they do. You'll need to show those scenarios and explain how this library qualifies as one. Given that, by definition, dependencies can only be accessed through an "API surface" (which is the only surface that matters), no matter how many times a dependency is duplicated, the number of attack vectors will most likely stay the same, unless duplicates somehow increase the API surface, or attackers somehow are able to exploit a package when duplicates exist, but not when duplicates do not exist.

Otherwise, mathematically it seems reasonable to assume that it's less likely for an attacker to exploit a vulnerability when duplicates do not exist. Prove me wrong.

Therefore, JS application developers are recommended to remove unused and duplicated packages from their projects

Removing unused packages is sound advice. Even better, don't add unused packages to your dependencies to begin with, use a linter to avoid this.

in order to eliminate the security risks unnecessarily incurred by those dependencies.

Correlation is not causation, and this doesn't really apply to this package anyway.

Execute the “npm dedupe” command

This is what you would do, as a user.

---

Your research should focus on encouraging maintainers to do the opposite of what you're saying. Rather than removing a commonly used package, they should search their dependency tree for similar packages that are not depended on as much, and remove those in favor of the one that is used more frequently throughout the tree. This strategy will allow tree shakers and duplication to be more effective.