Plan for 2.0.0 or other plan to address trim vulnerability?

[deej-split]

Hello all,

GitHub has told us that there's a security vulnerability in the trim@0.0.1 package, which is being used by remark-parse@8.0.3 which is being used by @mdx-js/mdx@1.6.22 (which, in turn, is being used by Storybook).

I see that there is a version 2.0.0 that has been underway for the last year which fixes this (by removing the dependency on remark-parse). I'm not seeing any discussion of doing another 1.6.x release that would move the dependency on remark-parse to 9.x.x (which I believe also fixes this by removing the dependency on trim).

My question for y'all is: Do you have any insights into when 2.0.0 might be released or whether you've thought of doing an updated 1.6 release?

Thanks!

[ChristianMurphy]

Please see the last three times this question has been asked https://github.com/mdx-js/mdx/issues?q=is%3Aissue+trim+is%3Aclosed+vulnerable

To reiterate:

1. This is not an exploit, it is a potential slow down. remark-parse 9, react-markdown 6, and mdx 2/xdm address this, and provide other performance improvements.
   https://overreacted.io/npm-audit-broken-by-design provides some additional insights into why npm audit and snyk, while useful, can also be broken for packages like react and mdx, flagging non-issues.
2. MDX version 1 cannot be patched (less strict version dependecy for "remark-parse" #1548 (comment))
3. MDX version 2 is stalled due to disagreements, in the meantime https://github.com/wooorm/xdm is available.

[ChristianMurphy]

It still seems like an issue.

Not really
https://github.com/wooorm/xdm#security

MDX is JSX and Markdown.
JSX includes JS and can run anything.

MDX should mainly be run with trusted content on a trusted environment.
And if content is untrusted, it needs to be sandboxed and rate limited.

For this to be an issue you'd need to run untrusted content without a sandbox or a rate limit.

[deej-split]

I see your point. Well stated. To put in my words what I think you said, this is a contextual security concern... "it depends".

I don't really know the solution to this class of problems, but I'll brainstorm a bit of something here. I'm like four levels away from the problem here, and as a consumer, I do not necessarily have visibility into whether an intermediate package has addressed a "general purpose" security concern like this, or what I'd need to do. in some idealized world, it would be great if something like trim could advertise in the package.json "I have an inherent risk, and here's some ways it might be mitigated" and intermediate packages could say "hey, wrt that concern from package X which is in my dependency tree, I have/have-not addressed it". Info like that would help things like nom audit give better guidance to app or library developers.

[ChristianMurphy]

Absolutely, a lot of security, and in particular supply chain security is contextual.

I agree that a mechanism in/for auditing tools, which allows downstream package maintainers to add commentary on impact and perhaps suggest a modified transitive CVSS score, could be beneficial.

There are also some other proposals floating around including: npm/rfcs#18 and https://twitter.com/dan_abramov/status/1412380714012594178

[deej-split]

Thanks!

[ChristianMurphy]

Another recent NPM RFC also aiming to offer a potential solution npm/rfcs#422