Closed bbimber closed 3 months ago
there are a number of things that actually make this a little trickier than face value, specifically that d3 adopted "pure ESM" modules in the version that fixes the vulnerability, and pure ESM modules are sort of a can of worms. bundlers for the web often smooth over these issues, but they are often very obvious when you try to use any jbrowse stuff in a nodejs environment (@jbrowse/img does this, as well as jest tests that use jbrowse, etc).
specifically, even if jbrowse is able to adapt to the pure ESM via custom nodejs and jest configs, having these pure ESM modules can be an additional headache for consumers of jbrowse packages e.g. our embedded modules. therefore, we have not, to date, adopted any pure ESM modules. in some cases we have "vendored" (copied the entire codebase of) some modules into our system to avoid this, but with d3, that would require copying almost the entirety of d3 to make that work because there are many interdependent modules
that is why this hasn't been done yet. we could try to find some sort of solution though...
ok, got it.
if it is any consolation, the vulnerability is very low impact with the maximum damage being "denial of service" (probably just client side in the browser, causing a 100%cpu) if a maliciously crafted regex gets into place (https://github.com/GMOD/jbrowse-components/security/dependabot/135)
link seems private so image below
random interesting note: the material-ui team went ahead and vendored d3 to solve basically this problem (see https://github.com/mui/mui-x/releases/tag/v7.12.0)
my last comment (https://github.com/GMOD/jbrowse-components/issues/4507#issuecomment-2263551705) actually was very serendipitous and allowed this to get a fix
should be released now in v2.14.0!
thanks!
Hello,
Our package depends on jbrowse, and we're getting vulnerability alerts about d3-scale, d3-interpolate and d3-color. Is there a chance you could upgrade them in jbrowse?
Thanks, Ben