[Bf-committers] "Security" gets in the way

[Remo Pini]

I probably should have said "replace Python with some other scripting
language". LUA was just an example and this really shouldn't end up
being a discussion about what other language this should be but rather
on what the overall course of action should/will be. I'm sure that there
are many option, LUA just came to my mind first, because I use it in
World of Warcraft *grin* and they have exactly the same issues (secure
vs. insecure script, context related rights, ...).

Cheers

Remo

> -----Original Message-----
> From: bf-committers-bounces at blender.org [mailto:bf-committers-
> bounces at blender.org] On Behalf Of horace grant
> Sent: Mittwoch, 28. April 2010 4:57
> To: bf-blender developers
> Subject: Re: [Bf-committers] "Security" gets in the way
> 
> On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt
> <btolputt at internode.on.net> wrote:
> > horace grant wrote:
> >> no need for lua. python is the much nicer language. :p there is
pypy
> >> which supports sandboxing and which also gets cpython api
compatible
> >> at the moment.
> >>
> >> http://morepypy.blogspot.com/2010/04/using-cpython-extension-
> modules-with.html
> >>
> >> in 2 years or so (once pypy is more mature and python 3 compatible)
> it
> >> should be no big problem to replace cpython with pypy. as another
> >> benefit pypy will be much faster than cpython due to its jit
> compiler.
> >>
> >
> > Whether Python is or isn't a nicer language depends on your point of
> > view, so I won't debate that.
> 
> 
> 
> yes, you are right, but i (and i am sure many others too) would really
> pity if python got removed from blender. if that really needs to
> happen then it would be better in my opinion to use the language
> agnostic mono instead of something like lua. i think mono has
> sandboxing features too.
> 
> 
> 
> >
> > However, the "sand-boxing" as presented in PyPy is very crude and
> will
> > do nothing to fix the issues with Python in Blender. The major
> problem
> > with Python in Blender is not that it can access files "in general"
> (as
> > that is a REQUIREMENT of import / export scripts for example) but
> that I
> > can access EVERYTHING Python can from every execution context. That
> is,
> > I might only want Python to have access to other elements in the
> scene
> > (say for a rig or controlling a particle simulation) but, so long as
> > Python can access files (which, as I said, is *required*) everything
> > executing Python code can.
> >
> > In Lua, AngelScript, Falcon, TinyScheme, etc it is possible to only
> > expose to the execution context that which you want it to have
access
> > to. If you don't want it to read/write files - don't give it the
> > necessary modules/functions. This is not possible in Python
> (everything
> > is accessible everywhere) and the sand-boxing in PyPy is an "all or
> > nothing" affair. Either you can access the file system or you
cannot.
> No
> > way to only restrict access in only some scripts (say those included
> in
> > the untrusted .blend file) and not others (those installed by the
> > end-user in the .blender/scripts directory). Not to mention the
> > performance issues with the method PyPy users (dual processes - with
> all
> > "sand-boxed" data needing to be marshalled between the
Blender/Python
> > process and it's sand-boxed proxy).
> >
> > Sorry, Python is designed in such a way as to make securing it an
> > unlikely scenario.
> 
> 
> 
> maybe blender developers could contact the pypy developers and discuss
> this whole thing? i am sure a solution can be found. pypy still is in
> development and nothing is final.
> 
> 
> 
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers