> I believe [Lua is] also much easier to secure / sandbox [than Python] Yes. C code that embeds the Lua VM has total control over which functions are exposed t

> I believe [Lua is] also much easier to secure / sandbox [than Python] Yes. C code that embeds the Lua VM has total control over which functions are exposed to the Lua code. It's possible to create a VM that, for example, has no access to the filesystem. AFAIK it's not possible to do that if you embed Python. Dangerous functions like `open` are always available and sandboxing facilities have to try and prevent untrusted code from getting a reference to them. Unfortunately, there are numerous ways to work around these restrictions and obtain access to dangerous functions, e.g. via `__builtins__`. Another reason running untrusted Lua code is considered fairly safe is that the VM is well-engineered and has a history of very few bugs [0]. However, the latest 5.4.0 release seems to have more bugs than older releases. It might still possible for untrusted Lua code to use 100% CPU and hang a program, or to read data from the embedding process using a Spectre-style attack (although even that's unlikely because the Lua VM is an interpreter rather than a JIT compiler). However, it's quite possible to secure an embedded Lua VM to prevent it from doing things like accessing arbitrary files. [0] https://www.lua.org/bugs.html https://www.lua.org/bugs.html