Two high security vulnerabilities in transitive dependencies of @commitlint/cli

joshuahatcher commented 2 years ago

cc @javoire

My organization maintains an internal package that was recently discovered to have a couple of high security vulnerabilities in transitive dependencies (namely, lodash.template and trim-newlines). Our package depends directly on @commitlint/cli, and in both cases the issues were downstream from @commitlint/cli. Upon investigating, I noticed that @commitlint/cli transitively depends on a package called git-raw-commits, which is apparently archived and read-only. Both offending packages/versions were transitive dependencies of this archived project. Git-raw-commits appears to also be owned by the conventional-changelog org.

Since these vulnerabilities stem downstream from git-raw-commits, and especially given that that package that is no longer maintained, I wanted to see if it would be possible to remove dependency on git-raw-commits from @commitlint/read (and therefore from @commitlint/cli). This would clear up both of these vulnerabilities, and allow us to continue using @commitlint/cli, which we would love to do!

The alternatives are slim, because in the case of the trim-newlines vulnerability, the version in which the vulnerability was resolved is totally out of range from what is being used downstream of git-raw-commits. And in the case of the lodash.template vulnerability, there is no patch/upgrade to resolve the vulnerability.

Expected Behavior

Running a Snyk vulnerability scan on a project that depends on @commitlint/cli does not detect downstream vulnerabilities

Current Behavior

Running a Snyk vulnerability scan on a project that depends on @commitlint/cli detects downstream vulnerabilities from trim-newlines and lodash.templates

Affected packages

[x] cli
[ ] core
[ ] prompt
[ ] config-angular

Possible Solution

Remove dependency on git-raw-commits, which is archived/read-only and transitively depends on the vulnerable version of these two packages

escapedcat commented 2 years ago

Looks like commitlint is also using this in the read packagre directly:

=> Found "git-raw-commits@2.0.11"
info Reasons this module exists
   - "_project_#@commitlint#read" depends on it
   - Hoisted from "_project_#@commitlint#read#git-raw-commits"
   - Hoisted from "_project_#lerna#@lerna#version#@lerna#conventional-commits#conventional-changelog-core#git-raw-commits"
   - Hoisted from "_project_#lerna#@lerna#version#@lerna#conventional-commits#conventional-recommended-bump#git-raw-commits"

If the issues come from lodash and trim-newline would a resolutions for these packages help?

Would you be able to create a PR?

joshuahatcher commented 2 years ago

Hi @escapedcat — correct, the chain of dependency is commitlint/cli > commitlint/read > git-raw-commits Then from there, the two vulnerable packages are a couple layers below.

Resolving for trim-newlines isn't ideal because the safe version is out of the range that is being used under git-raw-commits. Resolving for lodash.template wouldn't be possible, because there currently is no patch/upgrade for the vulnerability. And, of course, we can't update git-raw-commits because it's archived/read-only.

escapedcat commented 2 years ago

The github-raw-commit repo says:

deprecated, instead use https://github.com/conventional-changelog/conventional-changelog monorepo

More than happy to switch this to conventional-changelog. Happy for a PR or we could pair on this. Join our slack if you like to: https://devtoolscommunity.herokuapp.com/ (#commitlint).

conventional-changelog / commitlint