libv8-node VS dukpy

Cue libv8-node+mini_racer from which PyMiniRacer was born. It is non-trivial but not as hard as one might think.

The most painful part is the libv8 build system and Google tooling, which makes it an absolute PITA for libv8 consumers that are not Chrome.

This is why the libv8 gem was atrocious to keep up to date and to build for several platforms, and why libv8-node was born, because the node build system and source distribution are actually sane.

Disclaimer: worked at Sqreen, now maintainer of libv8-node and collaborator of mini_racer

https://github.com/sqreen/PyMiniRacer

https://github.com/rubyjs/mini_racer

https://github.com/rubyjs/libv8-node

oh good, maybe we can now use python's javascript interpreter in browsers https://github.com/amol-/dukpy

I was interested to see that this uses the DukPy wrapper around Duktape for the JavaScript interpreter: https://browser.engineering/scripts.html

This made me start digging into whether this was considered a "safe" way of executing untrusted JavaScript in a sandbox.

its not completely clear to me if DukPy currently attempts safe evaluation - it's missing options for setting time or memory limits on executed code for example: https://github.com/amol-/dukpy

There's a QuickJS Python wrapper here which offers those limits: https://github.com/PetterS/quickjs

I'm pretty paranoid though any time it comes to security and dependencies written in C, so I'd love to see a Python wrapper around a JavaScript engine that has safe sandbox execution as a key goal plus an extensive track record to back it up!

I didn't write it, but here you go. Thanks to the fact that you can pass Python arguments to the JavaScript function, it will nicely cast them for you (via JSON) and make them behave per a Javascript object, which can then do some funsies to make it act like a string.