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

Wed Apr 28 18:55:37 CEST 2010

+1
Dropping support for Python is going to be hard to accept for many.
-it is extremely useful and rich
-very easy/user friendly language
-closest to 'industry standard' for scripting languages, common in other
cg packages
-heavily and well integrated into blender 2.5
-ppl have invested lots of effort learning it
-ppl have invested lots of effort migrating to the new api
-Campbell is solving the security vs. usability issues, people who want
to run 'secure but less capable' will be able to, most people in
production settings will be running 'more capable but less secure' ,
however, these people aren't usually running outside files.


On Wed, 2010-04-28 at 13:31 -0300, malefico at licuadorastudio.com wrote:
> 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
> >
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers