RE: future of bytecode verifier

["John Hind" <john.hind@...>]

Safety is *always* relative! Lua does make some representations about the
scope of what can happen as a result of reading data via the Lua
code-reading channel (it will not crash the process or execute input bytes
as machine code for example). It is now being suggested that these
representations cannot be sustained for bytecode. In this case it must be
sub-optimal to have both bytecode and source code entering by the same
route.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Sam Roberts
Sent: 05 March 2009 17:26
To: Lua list
Subject: Re: future of bytecode verifier

On Thu, Mar 5, 2009 at 6:06 AM, Ralph Hempel
<rhempel@hempeldesigngroup.com> wrote:
> 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.

Lua isn't "safe by default" now. By default, it exposes the debug
library, and os.execute(). I like that. Running code of unknown
provenance, byte or string, is unsafe by its very nature.

Sam

Attachment: smime.p7s
Description: S/MIME cryptographic signature