Re: future of bytecode verifier

[Ralph Hempel <rhempel@...>]

John Hind wrote:

> This approach makes Lua "safe by default" and anyone implementing bytecode
> support is made responsible for the integrity of the bytecodes between write
> and read operations (for example by restricting to a protected store, or
> even by implementing cryptographic signing).

Strongly agree.

> Can I also request that consideration be given to sorting out the
> "endedness" problem for Lua bytecode? Either pick an endedness for the saved
> format and convert if necessary on both write and read, or if this is
> thought inefficient, have a flag for the endedness in the format and convert
> on read if necessary.

Strongly agree.

Going to the next incremental minor number has usually been the point
where breakage might occur, so 5.2 seems as good a place as any to get
this sorted out.

Ralph