Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reviving PyMiniRacer: A Python JavaScript Bridge

bpcreech.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Reviving PyMiniRacer: A Python <> JavaScript Bridge

#11

Post by mahmoudimus »

simonw wrote: post #3

This looks very promising! 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…

Google's Starlark is a pretty good python-like language that does a lot of what you want, we use it at my company to run untrusted code. It's not exactly python, but a pretty good subset. It's deterministic, hermetically sealed and non-Turing complete.

Re: Reviving PyMiniRacer: A Python <> JavaScript Bridge

#12

Post by jennasys »

leontrolski wrote: post #6

I'm always excited by the idea of rendering jsx from Python in the same process. Mostly as a bridge between eg. an existing Django app and full SPA React land. You'd swap out the scrappy Django string templating with jsx, then once a page passes some frontend interaction complexity threshold shift it over entirely (with shared components between both). Could this project help achieve this or are imports/build process…

I've made React applications using Python via Transcrypt, but wrap component functions in a Python decorator that make direct calls to React.createElement() instead of using JSX (example: https://github.com/JennaSys/tictacreact2). It's possible to use JSX with this approach as well, but IMO it starts to get messy and defeats the purpose of using JSX in the first place.

Re: Reviving PyMiniRacer: A Python <> JavaScript Bridge

#13

Post by bpcreech »

simonw wrote: post #3

This looks very promising! 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…

New owner here!

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.

Re: Reviving PyMiniRacer: A Python <> JavaScript Bridge

#14

Post by [deleted] »

mahmoudimus wrote: post #11
simonw wrote: post #3

This looks very promising! 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…

Google's Starlark is a pretty good python-like language that does a lot of what you want, we use it at my company to run untrusted code. It's not exactly python, but a pretty good subset. It's deterministic, hermetically sealed and non-Turing complete.

[deleted]

Re: Reviving PyMiniRacer: A Python <> JavaScript Bridge

#15

Post by simonw »

bpcreech wrote: post #13
simonw wrote: post #3

This looks very promising! 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…

New owner here! 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…

Blogged about it here https://simonwillison.net/2024/Mar/24/reviving-pyminiracer/

Re: Reviving PyMiniRacer: A Python <> JavaScript Bridge

#16

Post by jbaviat »

simonw wrote: post #3

This looks very promising! 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…

PyMiniRacer (original) author here. PyMiniRacer is definitely a way to run insecure code, but as pointed, the several CVEs in V8 require measures beyond "just" relying on PyMiniRacer to make it safe.

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!

Post reply on HN