Duktape misc. notes dump (so I can close a few tabs)

[jberryman]

• https://bellard.org/quickjs/ - somewhat faster, ES6 support; but it seems like it might not be configurable in the way we'll need for sandboxing in cloud (also they are both 1-2 orders of magnitude slower than jitted chrome, so not terribly convincing). Duktape seems very well documented and tested (they've even integrated it with a fuzzing framework)
• misc discussion: https://news.ycombinator.com/item?id=21931224 - generally people have had positive experiences with duktape. Discussion of other approaches
• ...also mentioned is https://www.moddable.com/faq.php#comparison , which would require a licensing agreement (haven't looked into this one)
• Figma's journey to designing a plugin system: https://www.figma.com/blog/how-we-built-the-figma-plugin-system/ - they are looking for an embedded language in the browser itself, seemed to only briefly consider duktape. Probably interesting, but not necessarily very relevant for us
• Haskell bindings: took a brief look, chrisdone has apparently done a little audit.
  • we will need to maintain hs-duktape or a fork ourselves, but this seems totally doable
  • we'll need to make it async exception safe and just generally do a cleanup (not a big deal)
  • understand the SIGVTALRM stuff here https://github.com/svaarala/duktape/issues/2241
  • extensive testing: passing a computation across threads (set thread time slice short), run a bunch of contexts in different threads concurrently, kill threads randomly make sure the context is usable after (or that things are not broken in other ways), throwing from haskell code we call back into from C; within hasura we'll also need to test our sandboxing
• sandboxing will be a big deal for us due to cloud, where admins are untrusted: https://github.com/svaarala/duktape/blob/master/doc/sandboxing.rst
• we should look at the duktape test suite, any old CVEs and changelog for memory safety issues fixed; we might like to do our own testing of JSON parsing if an existing test suite or fuzzing framework exists, since JSON inputs are untrusted for both cloud and on-prem/oss deployments

[jberryman]

Things we'll want to change or add in haskell bindings:

• should be IO not in MonadIO
• unicode arrows and stuff
• probably throw exceptions instead of returning, for certain operations
• try to put the duktape version in the version number, update the vendored lib
• overlapping instance IO () and IO value
• support for timeouts in eval/call
• ~ditch the custom Setup.hs, move that script into something we run at packaging time so folks don't need python2 as build dep~ edit: or maybe not... but probably ya
• review forks network for anything interesting

[GavinRay97]

Thank you Brandon, this is super valuable!

[jberryman]

I'm going to keep adding notes here @GavinRay97 , as I think of them. Also need to start a fork anyway to make more progress on the typescript POC

[jberryman]

More on security

There are two threat model scenarios:

• for OSS users: only JSON inputs are untrusted (and might exploit a bug in duktape parser, say), JS client code is admin and trusted
• for multitenant: JS client code is untrusted (and might exploit a bug anywhere in duktape, e.g. to own our servers or exfiltrate data from other tenants)

But eval() complicates the first scenario. We might wish to prohibit eval in duktape in order to protect customers in scenario 1 from injection attacks (which also breaks the threat model because it could allow an escalation from scenario 1 to scenario 2)

Not clear if we can actually do this without breaking code everywhere, but we'd need to shim/overwrite:

• eval
• setTimeout with string argument
• setInterval with string argument
• new Function with string argument
• .... others?

[jberryman]

Weird behavior related to cyclic objects to investigate

• passing cyclic object to haskell code results in immediate exit(0). This is very bad:

      const cycle = {};
      cycle.cons = cycle;
      console.log(cycle);  // Probably any exposed haskell func works here 
      console.log("We never get here");

  exit originates from some call to fastExit; trace further https://github.com/ghc/ghc/search?q=fastExit

  Breakpoint 1, __GI_exit (status=status@entry=0) at exit.c:139
  139 exit.c: No such file or directory.
  (gdb) bt
  #0  __GI_exit (status=status@entry=0) at exit.c:139
  #1  0x0000000000f04bb8 in stg_exit (n=n@entry=0) at rts/RtsStartup.c:646
  #2  0x0000000000f04eee in shutdownHaskellAndExit (n=0, fastExit=fastExit@entry=0) at rts/RtsStartup.c:579
  #3  0x0000000000f0eda1 in hs_main (argc=<optimized out>, argv=<optimized out>, main_closure=<optimized out>, rts_config=...)
      at rts/RtsMain.c:99
  #4  0x000000000041ccb6 in main ()

• empty panic message when we return cycle from a function we call using callDuktape (once we install a FatalFunction; otherwise we get SIGABRT, which is expected). This might be fine but the fact we don't get an error message is worrying

[jberryman]

duktape to test:

• quickcheck tests that roundtrip JSON, via function id(x) { return x }
• consider enabling assertions in duktape when testing bindings

to check:

• we don't pass any un-pinned references in safe FFI calls: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/ffi.html#unlifted-ffi-types (...and how might we try to test this. Triggering a bunch of GCs in another thread?)

misc:

• we can use the new (undocumented) JS config scripts rather than mess with python2