Setting boundaries with our dependencies?

we would like to be able to set boundaries with our dependencies. define what they can use and crash if they try to do anything else.

like, why do we need our file compression library to have access to anything more than (some amount of) regular RAM and the ability to do math on said RAM? (optionally it might be useful to give it file access, but that should only be for files we want it to access, or we can handle file access ourselves.) it doesn’t need to be able to load code, set breakpoints, access the internet, mine crypto, or anything of the sort.

ofc, our dependencies may have their own dependencies, and ideally they’d set and enforce boundaries all the way down. but outside of something like wasm components (which as far as we know we can’t use from python), we have no real way of doing that, and that’s before taking into account how this would require deep changes to python packaging. but maybe we can at least do it for our own dependencies?

click is very widely used. so is jinja. click needs env access (well, args and env) and we guess also stdio access? it doesn’t strictly require filesystem access. jinja, on the other hand, doesn’t need anything (okay, some folks would get angry if you didn’t support hot-reloading templates, but that can be dealt with without granting it full filesystem access - also our project personally doesn’t benefit from it so eh we should be able to give jinja nothing). but as far as we know we don’t currently have a way to set these security boundaries with our dependencies?

1 Like

interesting that thread mentions wasm too…

we know we shouldn’t chase specific solutions (“XY problem” and whatnot) but uh…

is there a way to include wasm-based dependencies into a python project? (ideally using the component model… writing wasm bindings by hand is a pain, from experience.)

(tbh we don’t even know how to use wasm from python… is there a way to do that?)