fix: upgrade marked to resolve ReDos vulnerability

[Trott]

This addresses GHSA-rrrm-qjm4-v8hf.
GHSA-rrrm-qjm4-v8hf

Accommodate breaking change in index.js. (Use marked.parse() instead of
marked().)

Bumps marked from 2.0.1 to 4.0.10.

• Release notes
• Changelog
• Commits

---

updated-dependencies:

• dependency-name: marked
  dependency-type: direct:production
  ...

[Trott]

This is the same as #2329 but with the needed changes to index.js to accommodate a change in the marked API.

[travi]

Thanks for the help with this. I think this will also require an update of marked-terminal for compatibility, which can be confirmed by running npm ls. Would you mind handling that part as well?

[Trott]

Thanks for the help with this. I think this will also require an update of marked-terminal for compatibility, which can be confirmed by running npm ls. Would you mind handling that part as well?

I've pushed a second commit for that. It needed a more extensive reworking of the code because marked-terminal@5 cannot be used via require. The integration test hooks are failing for me locally. I'm wondering if that is a problem on my end though?

[Trott]

The integration test hooks are failing for me locally. I'm wondering if that is a problem on my end though?

It was indeed a problem on my end. I think this is ready for code review.

[Trott]

I added a commit to update the engines field to comply with the complaint in https://github.com/semantic-release/semantic-release/runs/4828866235?check_suite_focus=true, but I don't know if that makes this semver-major by dropping Node.js 15.x support. I hope not.

[travi]

I don't know if that makes this semver-major by dropping Node.js 15.x support. I hope not.

It would. It wouldn't be a bad thing for us to drop v15 support at this point, but it would be best if we didn't have to require our consumers to upgrade past a major just to get the vulnerability patched.

Is there no combination of marked and marked-terminal that could resolve the vulnerability without needing to drop support for a node version that is currently supported?

[ReidWeb]

Observing as a consumer and thought I'd add a quick comment.

Is anyone out there really building production systems with Node 15? Node 16 is the active LTS, and Node 17 the current non LTS.

It's unlikely to impact many given 15 was never an lts, and isn't active. Feature parity with 15 is available in 16 iirc.

[Trott]

drop support for a node version that is currently supported

Just for clarity, you mean "supported by semantic-release" and not "supported by Node.js", right? Because as far as Node.js is concerned, 15.x is no longer supported. (Or does the not-supported-by-Node.js change anything here?)

Ref: https://github.com/nodejs/Release#release-schedule (TL;DR Only 12.x, 14.x, 16.x and 17.x are supported by Node.js right now. 15.x reached end-of-life in June 2021.)

[Trott]

Is there no combination of marked and marked-terminal that could resolve the vulnerability without needing to drop support for a node version that is currently supported?

That's correct: There is no combination that will resolve the vulnerability and support Node.js 15.x.

The last release of marked-terminal@4 is 4.2.0, which is compatible with marked@2 but not marked@4 (which contains the fix). So we have to use marked-teminal@5 to get the fix in marked. But marked-terminal@5 does not support Node.js 15.x.

Dropping support for Node.js 15.x (or supporting Node.js 15.x use and not worrying about marked-terminal because while I haven't tested I suspect it will work just fine with 15.x) is the easiest path forward. Another option would be to remove marked-terminal and use more generic output (either raw markdown or plain text). We could also look at replacing marked-terminal with something else. And we could also fork marked-terminal and/or look for a commit of marked-terminal to pin to rather than using an official release.

[Trott]

FWIW, I ran npm ci && npm run test using Node.js 15.x and all the tests passed.

[travi]

Just for clarity, you mean "supported by semantic-release" and not "supported by Node.js", right?

good clarification. yes, i mean currently defined as supported by semantic-release in engines.node for this package. i'm aware that v15 is EOL, which is why i am in favor of dropping support. i'd just prefer that it didnt have to be triggered as a result of this vulnerability.

That's correct: There is no combination that will resolve the vulnerability and support Node.js 15.x.

thank you for confirming. that's unfortunate, but not entirely surprising.

Another option would be to remove marked-terminal and use more generic output (either raw markdown or plain text). We could also look at replacing marked-terminal with something else. And we could also fork marked-terminal and/or look for a commit of marked-terminal to pin to rather than using an official release.

i appreciate the consideration of options. i have considered removing marked since compatibility between marked and marked-terminal has caused us trouble in the past. i would love it if there were an option to move in the direction of the suite of remark tools, but i haven't found a way to leverage them in the context of the terminal. i'd prefer to avoid taking on the effort of these options or the risk of more significant change to fix this vulnerability.

Dropping support for Node.js 15.x (or supporting Node.js 15.x use and not worrying about marked-terminal because while I haven't tested I suspect it will work just fine with 15.x) is the easiest path forward.

i agree that dropping v15 support is the best option. while v15 is EOL and impact would be low to treat supporting it less strictly, communicating impact of changes semantically is important to this project.

[travi]

thanks for digging into these details. this appears to be in good shape, but lets adjust the engines definition slightly as mentioned in the one comment i added

[travi]

just one more matrix adjustment

[travi]

thanks again for working through these details, @Trott. since this is a breaking change, i want to get another set of eyes on it before moving it forward and decide if any other pending changes need to be coordinated with it. i think this piece is ready to go and we'll work toward getting this finished up as soon as we can.

[gr2m]

I'm not very familiar with marked and its eco system. Can someone please explain the breaking change for semantic-release users? Is it only the drop of support for Node v15, or is there also an API behavior change related to the marked upgrade?

[Trott]

I'm not very familiar with marked and its eco system. Can someone please explain the breaking change for semantic-release users? Is it only the drop of support for Node v15, or is there also an API behavior change related to the marked upgrade?

There is no behavior change for the end user. The only user-visible issue is that a dependency (marked-terminal) no longer supports Node.js 15.x. As a result, npm will give an EBADENGINE warning on installation with Node.js 15. It's also possible that, as a result, markdown-to-ANSI-terminal features will break when logging to the terminal, but I doubt it.

[github-actions]

🎉 This PR is included in version 19.0.0-beta.1 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 19.0.0 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀