[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: future of bytecode verifier
- From: "John Hind" <john.hind@...>
- Date: Thu, 5 Mar 2009 11:15:58 -0000
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.
[mailto:email@example.com] On Behalf Of Luiz Henrique de
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
> 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
while Lua goes for the oposite.
Description: S/MIME cryptographic signature