2010/4/28 Remo Pini <[email protected]> > 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: [email protected] [mailto:bf-committers- > > [email protected]] 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 > > <[email protected]> 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 > > > [email protected] > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
