RE: future of bytecode verifier

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

Now you really have me confused! Surely most Lua apps accept "arbitrary user
code"? After all it is a configuration and customisation language and this
is the whole point. Sure, I guess most such apps do not *expect* to load
binary files, but as long as they use the same input stream this will remain
a possible attack vector. The main risk, as long as binary and text files
use the same input stream, must be that an attacker replaces a Lua source
file with his own binary file of the same name?

-----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 14:08
To: Lua list
Subject: Re: future of bytecode verifier

> You are suggesting that lua_load is still there but is administratively
> deprecated and new code is encouraged to use a new function, luaL_load
> instead? So luaL_loadbuffer, luaL_loadfile and luaL_loadstring would all
> require the extra "nobinary" flag as well?

No, only those apps that accept arbitrary user code. Those would use
luaL_load
if they want to avoid running user code in binary. Existing apps that run
binary code from known, safe sources, such as their installation
directories,
don't have to change anything. We expect those are the majority of the apps.
But perhaps our perception of what apps are out there is wrong.

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