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

[malefico at licuadorastudio.com]

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