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

[Benjamin Tolputt]

Jason Wilkins wrote:
> I think this is incorrect.  The way PyPy is implemented presents a possible
> solution.  Depending on the maturity of PyPy this may be ways off, so I'm
> just throwing this out to be considered.
>
> PyPy is a meta-circular interpreter, what that boils down to is the fact
> that you can implement a python interpreter in the language with a small
> amount of python code.
>   

I am not against an embedded Python interpreter at all. In fact, if you
look at my recent comments I'm kind of leaning that way. It is not the
"concept" I think will not work, but the "current PyPy implementation"
which is unworkable.

The current sandbox implementation of PyPy is a crude "all or nothing"
mechanism. Which works well for running Python where you want the same
permissions throughout the application. This is not the case in Blender
where plugins need access to the network & file system but the scene
itself does not.

On the other hand, extracting a Python interpreter that only allows the
calling of white-listed functions and limits the namespace to the data
within the scene only (i.e. I cannot find restricted modules/data by
browsing the namespace) from PyPy or another program is not a terrible idea.

I believe that resistance to this idea is based around the very valid
question of "Who is going to maintain this subset interpreter?". What
happens when PyPy makes an incompatible change or the standard Python
distro moves ahead of PyPy and there is a mismatch between the syntax
semantic used in scripts & scene drivers? These are all valid concerns
for a "graphics application project" without a huge pool of "Python
engine coders" available.