Skip to content

POV: rlua should only be concerned with rust-side safety and soundness #201

Closed
@SoniEx2

Description

@SoniEx2

Currently, rlua does some stuff like:

  • remove debug
  • remove native modules
  • remove bytecode loading
  • replace pcall/xpcall/etc
  • replace coroutines? (see also: pcall/xpcall/etc)
  • among other things

In other words, it attempts to be a Rust-based implementation of OpenComputers, a Lua sandbox. At this point, why not just use wasm instead? - which incidentally is something we're attempting to do with OpenComputers because it provides better sandboxing than trying to patch Lua, and allows exposing all the APIs without worrying about holes.

Instead, "High level Lua bindings to Rust" should be just that - bindings, not an entire sandbox!

References: #116 , README, [...]


If you take our former hexchat-plugin crate as an example, for making hexchat plugins, it does its best to prevent the Rust plugin from having bugs, but doesn't try to actively prevent other plugins from having bugs that interact badly with the Rust plugins. (where possible, we tried to submit upstream patches to hexchat instead, altho we didn't have much success with that because we were kind of a prick back then. >.<)

So we do think things like handling userdata soundness (#19) is important, even when the Lua code is explicitly calling __gc on the userdata twice. But it should not be implemented through "replacing Lua".

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions