Transform which ran with v1 not working with v3

[rreusser]

Hi! cwise has had some long-running issues/PRs to upgrade its usage of static-module and get rid of some security warnings, but it seems that the particular usage static-module is no longer functioning under static-module 3.*.

The cwise transform finds references to var cwise = require('cwise'); cwise({...}) and replaces them with evaluated code.

I'm guessing a bit, but it seems like maybe the usage as a bare function require as opposed to properties on the require (i.e. require('cwise')(...) as opposed to require('fs).readFileSync(...)) are not working.

FWIW, the transform has not changed and so does still function and get triggered correctly.

I've detailed a test case here.

Glad to debug a bit further, but I'd thought I'd check to see if this might just need a small API usage update instead of involved debugging. Thanks!

/cc @archmoj @etpinard

[goto-bus-stop]

i'll have a look at this tomorrow. the big change in v3 was that unknown uses of a module are now kept, instead of removed (risking runtime errors). but v3 also added scope tracking which was a fairly large refactor that may have broken some stuff!

require('xyz')('') is at least "intended" to work, but maybe it's bugged.

[goto-bus-stop]

the new static-eval doesn't support function expressions like the body option in:

cwise({
  body: () => {}
})

I think because of this patch browserify/static-eval#18

static-module has a special case for function arguments as callbacks:

readFile('xyz', function () {})

but not for object expressions. It might be a bit harder to do the same for those :/

A possible solution may be to have a static-module option or a method like staticModule.ast that passes the parsed AST nodes to functions, instead of statically evaluated values. cwise could use static-eval to evaluate strings and other primitive types and stringify the AST for function arguments using escodegen.

[archmoj]

@goto-bus-stop possibly any update on this?

[goto-bus-stop]

no, i forgot about it 😄 i'll aim to work on this on Friday. a PR would be welcome as well of course. I think the way to go here is to change the current code to pass in ASTs, which can be exposed as staticModule.ast, then implement the current API in terms of that.

[archmoj]

Many thanks @goto-bus-stop.
That would be great news for maintaining many webgl modules.
cc: @etpinard

[archmoj]

@goto-bus-stop My apologies for asking one more time.
Wondering if there may be progress on this issue?
Many thanks.

[goto-bus-stop]

The refactor is a bit trickier than I anticipated, and I haven't had the time to make it work yet unfortunately :(

[Domino987]

Hi @goto-bus-stop , i was wondering if you could refactor it?

[telamonian]

Hey @goto-bus-stop, thanks for working on fixing the issues with cwise and static-module. I have a professional interest in seeing cwise get upgraded past its security issues. Currently at my company, cwise's security issues are a blocker for all of the (way upstream) Jupyterlab Plotly extensions, which all depend on cwise through numerous dependency chains.

If you're still interested in working on this fix, I'd be more than glad to pitch in some of my time to help. Is your work so far on the refactor publicly viewable anywhere?

[goto-bus-stop]

@telamonian I think I tried a few approaches but none of them worked out so I discarded them.

For now @archmoj's approach where we just add an option to opt back into the unsafe behaviour is likely best—it's only insecure if you use it on untrusted code anyway…