|Daniel Salazar - 3Developer.com||Apr 27, 2010 6:00 pm|
|Matt Ebb||Apr 27, 2010 6:17 pm|
|Benjamin Tolputt||Apr 27, 2010 7:09 pm|
|Benjamin Tolputt||Apr 27, 2010 7:25 pm|
|Matt Ebb||Apr 27, 2010 7:33 pm|
|Benjamin Tolputt||Apr 27, 2010 7:57 pm|
|Campbell Barton||Apr 28, 2010 1:04 am|
|Daniel Salazar - 3Developer.com||Apr 28, 2010 1:14 am|
|Remo Pini||Apr 28, 2010 1:34 am|
|Benjamin Tolputt||Apr 28, 2010 2:36 am|
|horace grant||Apr 28, 2010 4:28 am|
|Benjamin Tolputt||Apr 28, 2010 7:06 am|
|horace grant||Apr 28, 2010 7:57 am|
|Remo Pini||Apr 28, 2010 8:32 am|
|Nery Chucuy||Apr 28, 2010 8:42 am|
|Raul Fernandez Hernandez||Apr 28, 2010 8:59 am|
|male...@licuadorastudio.com||Apr 28, 2010 9:31 am|
|Bassam Kurdali||Apr 28, 2010 9:55 am|
|Raul Fernandez Hernandez||Apr 28, 2010 10:59 am|
|Makslane Rodrigues||Apr 28, 2010 1:52 pm|
|horace grant||Apr 28, 2010 2:28 pm|
|Matt Ebb||Apr 28, 2010 2:34 pm|
|Charles Wardlaw||Apr 28, 2010 2:59 pm|
|Makslane Rodrigues||Apr 28, 2010 3:15 pm|
|Tom M||Apr 28, 2010 3:16 pm|
|Ruslan Merkulov||Apr 28, 2010 4:33 pm|
|Charles Wardlaw||Apr 28, 2010 5:09 pm|
|joe||Apr 28, 2010 5:21 pm|
|Benjamin Tolputt||Apr 28, 2010 5:31 pm|
|Ruslan Merkulov||Apr 28, 2010 5:40 pm|
|Benjamin Tolputt||Apr 28, 2010 6:45 pm|
|Martin Poirier||Apr 28, 2010 8:02 pm|
|amrp...@gmail.com||Apr 28, 2010 8:27 pm|
|Charles Wardlaw||Apr 28, 2010 8:44 pm|
|Benjamin Tolputt||Apr 28, 2010 8:57 pm|
|Martin Poirier||Apr 28, 2010 9:02 pm|
|§ĥřïñïďĥï Ŗäö||Apr 28, 2010 9:03 pm|
|Harley Acheson||Apr 28, 2010 9:31 pm|
|Benjamin Tolputt||Apr 28, 2010 11:23 pm|
|55 later messages|
|Subject:||Re: [Bf-committers] "Security" gets in the way|
|From:||Remo Pini (remo...@avexys.com)|
|Date:||Apr 28, 2010 8:32:27 am|
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, ...).
-----Original Message----- From: bf-c...@blender.org [mailto:bf-committers- boun...@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 <btol...@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.
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
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.