RE: future of bytecode verifier

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

OK, but I do not think the proposed mechanism is optimal, at the 'C' level.
Firstly the lua_Reader function replacement has to process the internals of
the bytecode format thus breaking containment, and secondly it still has to
pass the data on through a channel which is *capable* of bypassing the
parser opening an unnecessary route for potential exploitation.

Perhaps you could have lua_loadtext and lua_loadbinary and ship a lua_load
compatibility function which first tried lua_loadbinary and if that failed
switched to lua_loadtext? This would allow the definition of different
lua_Reader functions for binary and text.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Luiz Henrique de
Figueiredo
Sent: 05 March 2009 10:36
To: Lua list
Subject: Re: future of bytecode verifier

> 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).

This would break existing programs, though. And it'd be policy not
mechanisms,
while Lua goes for the oposite.

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