chore: update dependencies

[j9t]

Bumped dependencies by some simple npm audit fix. Though according to npm, this fixed 12 of 15 vulnerabilities, 3 persist; left it there for this update.

[j9t]

Btw, when testing, I ran into some issues with ESLint. If not already in progress or pointed out elsewhere, should be worth looking into. html-minifier is using a now deprecated way of configuring ESLint; still, the current issues may be treatable by adding and adjusting

"parserOptions": {
  "ecmaVersion": "latest"
},

in the config.)

[GintasS]

Hi there. Thank you for your work. Do you think your PR fixes this CVE?

https://www.mend.io/vulnerability-database/CVE-2022-37620

[DanielRuf]

@GintasS no, since the relevant code (see my comments in the relevant issue) is in this package and not one of its dependencies.

[j9t]

Quick side note, I had already taken the silence here and no updates in the slightly more up-to-date html-minifier-terser to fork that and spin another version of html-minifier: html-minifier-next (npm).

It’s already more up-to-date, it works, I use it with 3 projects, but I’m still slow to announce its availability. Sharing if others like to test and contribute 🤝

[DanielRuf]

I think the problem still exists there: https://github.com/j9t/html-minifier-next/blob/8b5c3f7f39fd69fbd1d9ab11bc3412f0ec0f04e4/src/htmlminifier.js#L891

See my analysis starting at #1135 (comment).

So until this vulnerable regular expression is not changed (meaning: gets some upper limits or some other change to prevent this ReDoS), even the fork may be vulnerable (actually not tested by me).

I'm not an active contributor and maintainer anymore, but if you need some input for this just let me know.

[j9t]

@DanielRuf, thanks! Not my domain expertise but I’ve thrown some tooling at a PR to, ideally, resolve that issue in html-minifier-next (and inform similar fixes): j9t/html-minifier-next#20. If you like to have a look at provide feedback, it would be appreciated! (Thanks already for the updates here!)