Re: Is Lua used as a data representation language?

[Hadriel Kaplan <HKaplan@...>]

Yes if you accept data from the outside world you'd be optimistic to blindly execute it as code, hoping it only builds a benign data structure.  But that's a choice the programmer can make - they don't have to use the loadstring function as ltin.lua does right now, but can instead use a library/function that only accepts and creates what they allow (assuming one writes such a function/library).  

Having said that, there are reasonable use-cases for keeping the data structure syntax/format a subset of Lua's grammar/rules such that something like loadstring could work - for example, the use-case of MPI messaging between Lua states in separate threads; or a program written for a private network environment (e.g., a distributed testing program for SQA labs).

Obviously everyone can create their own format and write their own serializer/deserializer for their specific use-cases, but it would be nice if there were a common/popular format so that a C-library to do the work gets wide review for stability and safety.  And to be so popular, I think the format needs to support as many use-cases as possible, including those for which a loadstring approach can be used instead of a C-library.

-hadriel


On Jan 8, 2013, at 12:05 PM, Robert Virding <robert.virding@erlang-solutions.com> wrote:

> I don't think being defensive is good enough here. If you are accepting "data" into your system from the outside world you really have to be paranoid and assume they are out to get you. Because they will be! It is not much different building firewalls where the safest way is to start by blocking everything and then only allow the bare minimum. Depressing perhaps, but the only safe way to go.
> 
> Robert 
> 
> ----- Original Message -----
>> From: "Thijs Schreijer" <thijs@thijsschreijer.nl>
>> To: lua-l@lists.lua.org
>> Sent: Tuesday, 8 January, 2013 11:19:56 AM
>> Subject: Re: Is Lua used as a data representation language?
>> 
>> 
>>> I think that having a data representation language which is
>>> executable is
>>> extremely dangerous and I would never use it unless the "data" came
>>> from an extremely trusted source. Basically myself. Even if I had
>>> written
>>> my own interpreter for it. This is one case where data should
>>> definitely
>>> be data and nothing else.
>>> 
>>> Robert
>> 
>> In general I would agree to that, but it is also a very defensive
>> point of view. I would like to see where this is going and whether
>> it can be sandboxed well enough to be safe enough (whatever that
>> might be).
>> If you don't try, you won't know.
>> 
>> Thijs
>