"uv run" seriously needs a sandbox. Running arbitrary code from arbitrary dependencies with 0 version locking provides no guarantees on what you are actually running.
Implementing sandboxes is really hard... but Astral are demonstrable great at solving hard problems. I dream of them one day saying "we've solved sandboxing for Python scripts" ala Deno https://docs.deno.com/runtime/fundamentals/security/
It might be a cool thing for them to provide some kind of container metadata in the `# /// script` block so that e.g. it automatically runs the script in a container.
I took gp’s comment to mean something more like deno. Deno is nice because you can explicitly allow/deny filesystem, network, etc. in an ergonomic way like `—-allow-fs`
So not sure it would necessarily be ergonomically worse. It could even be a new run command `uv srun` or something…
uv run is using virtual envs, that's the de facto standard, and those are sandboxes for python deps. So it already is.
Plus inline deps mean you can pin python versions and 3rd party modules using pyproject.toml syntax in a comment of your script. This is not perfect locking, as it doesn't pin sub dependencies, but it's already more that any other tool out there.
If you want perfect locking, create a project, and use uv lock. You are already in a different category of code.
OP isn't talking about virtual environment style sandboxing, they're talking about sandboxes that prevent arbitrary code from deleting or stealing any information your user account has access to on your computer.
This has been attempted many times with python, and always been a failure because of the dynamism of the language, even by big actors.
The solution, therefor, as always been to use the OS tooling for that. Even the .Net ecosystem eventually went into that direction.
The JS ecosystem is making that mistake right now, and will of course, deprecate this API in 10 years after they realize they can't make it secure either unless they basically reimplement BSD jails entirely.
Docker isn’t a sandbox and shouldn’t be treated like one. Admittedly if I’m going to run untrusted code I’ll run it in Docker, but I’m aware that whatever I’m running could break out. I wouldn’t blindly run some bullshit even in Docker unless I’m 90% sure it’s safe already.
Docker's primary purpose is to give applications their own namespaces in which they can run without conflict. It does confine applications to their own root filesystem, own process namespace and so on, but this isn't intended as a security boundary. cgroup escapes happen.
Firecracker and gVisor provide much stronger isolation. Both are battle tested; clouds run millions of multi-tenant workloads on these every day. Docker would simply never even be a candidate for this purpose.
>but I’m aware that whatever I’m running could break out
If you have a working docker escape exploit at hand, that works on unprivileged containers, you can earn some good money. Just saying.
Docker was not created as a sandbox, but people rely on it for security and it is a sandbox at this point. Hell, containerd is one of kuberbetes backends and it absolutely relies on it being a secure sandbox.
This is an interesting development, especially considering the growing trend of code-sharing platforms. As others have pointed out, this move by GitHub to allow UV to run GitHub Gists blurs the lines between code hosting and execution environments. It's worth noting that this also puts UV in direct competition with other code execution services like Repl. it and Google Colab, both of which have been gaining traction in the developer community. I'm curious to see how UV will differentiate itself in this crowded space.
No? Well, you can:
uv run https://pastebin.com/raw/RrEWSA5F
And since yesterday, you can even run a github gist:
uv run https://gist.github.com/charliermarsh/ea9eab7f56b1b3d41e5196...