What ?! how come the discussion started with "current blender defaults are getting in the way with production" which I totally agree and switched to "Let's replace Python with something else" ???
I'm sure there must be a clever way to solve this or maybe this "security problem" Regards malefico. > 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 > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
