The problem I most want to solve with this kind of library is execution of untrusted user-provided code in a sandbox.
For that I need three things:
1. Total control over what APIs the user's code can call. I don't want their code being able to access the filesystem, or run subprocesses, or make network calls - not without me explicitly allowing a controlled subset of those things.
2. Memory limits. I need to be able to run code without fear that it will attempt to allocate all available memory on my computer - generally that means I want to be able to set e.g. a 128MB maximum on the amount it can use.
3. Time limits. I don't want someone to be able to paste "while true() {}" into my system and consume an entire CPU thread in an infinite loop. Usually I want to say something like "run this untrusted code and throw an error if it takes more than 1s to run"
My most recent favourite solution to this is the https://pypi.org/project/quickjs/ Python library wrapper around QuickJS, which offers those exact features that I want - memory limits, control over what the code can do, and a robust time limit.
(The one thing it's missing is good documentation, but the https://github.com/PetterS/quickjs/blob/master/test_quickjs.... test suite covers all of those features and is quite readable.)
Can PyMiniRacer handle those requirements as well?
It should indeed be able to handle those requirements, and I think that matches the original use case from Sqreen.
Obviously, of course, there is no warranty and especially since I only recently adopted this project, I'd encourage anyone using this to run untrusted code go over the codebase and its assumptions very carefully.
And as far as running untrusted code goes, anything running V8 is subject to V8's stream of CVEs: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=v8. Whereas V8 in your browser gets aggressively auto-updated by the browser's auto-update feature, PyMiniRacer's update schedule is unlikely to be as reliable (and depends on your own action to update your pip installation!).
N.B.: the memory limits operate on a per-context (per MiniRacer object) basis, even though (for historical reasons) you can (attempt to) set them on a per-eval basis.
For the record PyMiniRacer was victim of a CVE itself https://nvd.nist.gov/vuln/detail/CVE-2020-25489 - a heap overflow, my mistake.
1. Total control over what APIs the user's code can call: you kinda got it... users can just do plain JS 2. Memory limits: you got it 3. Time limits: you got it, but the current model is unreliable when used at high levels of CPU and a high number of threads.
And thank you so much bpcreech for taking back the ownership of PyMiniRacer!
It's still not quite as easy as I want it to be!
call(expr, *args, encoder=None, timeout=None, max_memory=None)