If you're just looking to run trusted scripts locally, there isn't much point. If you're running a system that uses wasm, this means you can now easily support Python.
I don't see how this would in any way prevent you from being affected by a equivalent poisoned pypi dependency; after all your secrets/credentials are inside the sandbox anyways or your code can't work.
With Wasm + WASI, you need to explicitly mount files and environment variables. Inside the Wasm VM, the Python interpreter, source code and dependencies only have access to a very reduced surface. Although you're right that if you mount credentials inside, they will be accessible too.
The incident I was talking about was the event-stream[1] vulnerability. The attacker introduced code that looked for the data of a crypto wallet. This data was stored in the user's home.
By default, interpreters may get access to the same resources that the user running the process. In Wasm, the resources are granted manually.
> By default, interpreters may get access to the same resources that the user running the process. In Wasm, the resources are granted manually.
What's the difference to run the code under a different user (like for example `nobody` for "full sandboxing", or a "clone of nobody" with some additional access rights)?
Running code under a different user is hard. I don't know how I would do that on macOS, and the times I've done it on Linux I've always had to jump through a bunch of hoops.
MacOS aside, as this is not a serous operating system for this kind of workloads, do you think the "hoops" (which actually?) one needs to "jump through" are so problematic that it makes sense to create millions of lines of new code just to work around them? Only to arrive at the same result that is already working since something around 50 years? This must be really grave issues with just running a task as a different user… Could you expand on that?