Re: future of bytecode verifier

[Roberto Ierusalimschy <roberto@...>]

> Basically I see two relevant use cases:
> 1) I load untrusted code which runs loadstring on evil bytecode that can
> hack my machine.

When you run untrusted code, you already have to constrain what functions
it can use. So the point is whether loadstring should be considered
a safe or an unsafe function. 

Our problem is a conflict between compatibility and security. If we
favor compatibility, we should keep loadstring/loadfile accepting "evil
bytecode", and those concerned with security issues should correct their
code. If we favor securiy, we could make loadstring/loadfile refuse
"evil bytecode", and those concerned with compatibility should correct
their code.

I see two points to favor compatibility. The first (and stronger) is
that the current loadstring/loadfile is already broken. We will not
break compatibility in a bug-fix release (5.1.5), so those concerned
with security will either wait for 5.2 (many months ahead) or will have
to fix their code now, anyway. The second reason is that we believe
there are much more people using loadstring/loadfile in "normal"
use (not running or being called by untrusted code) than in special
uses. (I am mostly sure this is true for loadfile; may not be true for
loadstring, though.) So, by favoring compatibility we would annoy less
users.

-- Roberto