On 30 apr 2010, at 12:00, [email protected] wrote:

> Triggered by the crazily exploded security/sandboxing talk, I looked a 
> bit into what kind of mathematical expression parsers etc. 

well, I was triggered too, and having just recently thought about pragmatic en 
pythonic ways
to get around with sandboxing and downscaling Python without giving up its 
basic elegance as
front-end for artistic programming, I decided to become finally a bit active in 
this mailing list;

my basic approach is the other way around of parsing source code: making 
decorators
that analyse generated byte-code and even transform byte-code; I have used this 
in an IDE
for advanced impact-analysis and global flow analysis that work through 
metaclasses
(in contrast to pychecker), and also for generating 'bytecode' for extreme 
small sensor nodes.

at this moment I am working on a bridge between Python and Lua, it is a chunk 
decorator that
maps Lua syntax and semantics 1-1 on natural Python syntax and semantics, it 
executes
directly within Python, and its __str__ produces the equivalent LUA source code;

and this is my pragmatic and scalable suggestion towards more security:
the total amount of Python code in a Blender application in general will not be 
that huge (< 10000 lines);
Pythons standard compiler is very fast, and filters on produced byte-code can 
be fast too.
if such filters classify compiled code in a certain scale of trust, it is up to 
the user (or moderator) to
do some code inspection of indicated low trust without the need to look 
everywhere.

~Theo

_______________________________________________
Bf-committers mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-committers

Reply via email to