cz-conventional-changelog icon indicating copy to clipboard operation
cz-conventional-changelog copied to clipboard

Vulnerability warnings with ansi-regex and minimist

Open Blackbaud-SteveBrush opened this issue 2 years ago • 11 comments

I'm seeing a few vulnerability warnings after installing 3.3.0, namely with ansi-regex and minimist.

Blackbaud-SteveBrush avatar Apr 28 '22 19:04 Blackbaud-SteveBrush

Related: https://github.com/commitizen/cz-cli/issues/914

Blackbaud-SteveBrush avatar May 10 '22 12:05 Blackbaud-SteveBrush

@LinusU any chance to make an update of dependencies to fix outstanding security warnings ? its very hard to use the package in any continous integration build if critical vulnerabilities are shown when doing: npm audit

Thanks

igorlino avatar Jul 01 '22 17:07 igorlino

The issue is in commitizen 4.2.4. It was resolved in commitizen 4.2.5.

─┬ [email protected]
 └─┬ [email protected]
   └── [email protected]

I tried to fix it by manually installing 4.2.5 and using resolution until this library is updated (if ever, it looks abandoned - no updates since 2020), but it breaks the build.

"resolutions": {
    "commitizen": "4.2.5",
    "minimist": "1.2.6"
},
/Users/me/project/node_modules/listr2/node_modules/slice-ansi/index.js:2
const isFullwidthCodePoint = require('is-fullwidth-code-point');
                             ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/me/project/node_modules/is-fullwidth-code-point/index.js from /Users/me/project/node_modules/listr2/node_modules/slice-ansi/index.js not supported.
Instead change the require of /Users/me/project/node_modules/is-fullwidth-code-point/index.js in /Users/me/project/node_modules/listr2/node_modules/slice-ansi/index.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/Users/me/project/node_modules/listr2/node_modules/slice-ansi/index.js:2:30)
    at Object.<anonymous> (/Users/me/project/node_modules/listr2/node_modules/cli-truncate/index.js:2:19)
    at async Promise.all (index 0) {
  code: 'ERR_REQUIRE_ESM'
}

stevensacks avatar Jul 25 '22 08:07 stevensacks

@jimthedev @dmwelch When can we expect an update to this library to use 4.2.5?

stevensacks avatar Jul 25 '22 08:07 stevensacks

When can we expect an update to this library to use 4.2.5?

commitizen is defined as a range. while i support the minimum of that range being updated to force installation of the patched version, simply reinstalling/updating your lockfile can already allow you to use the patched version

travi avatar Jul 25 '22 16:07 travi

So you’re not going to release an update, something that would take you a few minutes, and instead off-loading the burden to every developer who uses this library to manually hack their package-lock file?

stevensacks avatar Jul 25 '22 23:07 stevensacks

you’re not going to

I'm not a maintainer. I can't make releases any more than you can. I was simply suggesting a solution that you could unblock yourself with in the meantime.

travi avatar Jul 25 '22 23:07 travi

Ah I was confused by you saying “while i support the minimum of that range”. It made it sound like you were a maintainer.

stevensacks avatar Jul 26 '22 00:07 stevensacks

Ah I was confused by you saying “while i support the minimum of that range”.

that statement was meant to clarify that i do think it is worthwhile for the change to be made in this project, even though there is a valid work around now available.

regardless of whether i was a maintainer or not, please consider the service that maintainers of OSS provide for free in their spare time. being confrontational or acting entitled to their service can actively discourage them from spending effort on the tasks you would like to have completed, or even end up burning them out further than they may already be. i find commitizen to be an important project and would hate to see it end completely.

travi avatar Jul 26 '22 02:07 travi

Hold up. Let’s clarify something. Your message read to me like you were a maintainer of this project, which meant you took time to reply on a thread giving an excuse why you weren’t going to release an update to resolve a vulnerability, when actually resolving it would have taken less time. If that was what happened, that would have been undeniably bad behavior on the part of the maintainer and it is not acting entitled to point that out.

stevensacks avatar Jul 26 '22 03:07 stevensacks

It would take the same amount of time to update the version of a single dependency as it would to make an excuse why you aren't going to.

This project hasn't been updated in over 2 years. I don't know what you're worried about. It's already been abandoned. Clearly the maintainer has already checked out.

stevensacks avatar Jul 26 '22 04:07 stevensacks