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

[Nery Chucuy]

2010/4/28 Remo Pini <remo.pini at avexys.com>

> 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, ...).
>
>
In this case I would say: how many problems have come up related to
security? and you're talking on changing Python because of that. I know it
might be something we need to discuss for the future but for now it's not a
big problem as far as I know. As someone said, if somebody wants to
dirty-hack something, he/she will find the way, that doesn't mean we won't
care on security but we cannot make it 100% secure as well.

I don't really think that we are moving from Python any time soon. Python
has been doing a great job and is deeply embedded in Blender. I think
talking on this is not even fair with all the great job as for example
ideasman has been doing the last years with the Python API.

I would suggest then to be focused on a Python solution.

regards,

-idesisnery



> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>