RE: [ANN] Luabins ? Trivial Lua Binary Serialization Library

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

My point is simply that the VM-Code load feature is already there - using it
for serialisation does not make it any more hazardous than it already is.
The only way of ensuring safety is to ensure Lua only reads from sources
that cannot be written from outside the controlled system. This is
straightforward for serialisation - make sure it only reads from a place
that only it can write to - with control of what gets written, you can
control what gets read. This is the same as for reading scripts - you have
to make sure they do not get replaced by malicious ones - either source code
or VM-Codes.

But I am not arguing that there is no place for a different serialiser, I
was responding to Alexander's criticism of the VM-Code approach, not to the
Luabins announcement.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Alex Davies
Sent: 23 February 2009 13:16
To: Lua list
Subject: Re: [ANN] Luabins ? Trivial Lua Binary Serialization Library

John Hind wrote:
> I'm with Luiz on this one and I think your objections are misguided:

I don't quite understand where you're coming from - he's concerned about the

security of bytecode when loading serialized data.  Obviously the algorithm 
itself will generate safe code - but who's to say the file you're loading 
from disk was generated by the algorithm?  It could have been modified. 
There are vulnerabilities in the current bytecode verifier (minor, but seg 
faults can be raised), and the fact that more may be found is a deterrent. 
Even if the bytecode is completely secure, and the file is run in a complete

no-globals sandbox, it can still lock the program in an infinite loop. 
(Which was his other deterrent).  Then there is the speed issue - if you're 
trying to pass data between lua_states in memory this could become a 
problem.

But for most applications the bytecode serializer sounds like a better idea 
imo.

- Alex

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