[Bf-committers] Please turn off Auto Run Python Scripts by default

Campbell Barton ideasman42 at gmail.com
Wed Jun 5 22:29:15 CEST 2013


On Thu, Jun 6, 2013 at 5:21 AM, Jace Priester
<jacepriester at threespaceimaging.com> wrote:
> Another +1 for not changing the OS module, or anything else for that
> matter. I use lots of python system-related modules, including OS, in my
> import/export/interop pipeline. If it is broken I will most likely not be
> using blender anymore (seriously).
>
> Additionally, I don't believe security in blend files is an issue anyway.
> If you have accepted a file from an untrusted source and opened it, YOU are
> the security risk, not the program you opened it with. AVIs, DOCs, and
> various other data files have had and still do have security risks
> associated with them (whether internal scripts are allowed to run or not).
> This problem is certainly not unique to blend files, and certainly not due
> solely to the fact that blender allows python scripts to run. This is a
> non-issue.
>
> The "Trusted Source" checkbox is a nice feature, I guess, but realistically
> I've never used it because I want all blends to open and work as intended
> by the creator. If I think it might be a malicious file, I don't accept it
> in the first place. That's where security starts, and ultimately ends.

Developer working on the bug tracker you have to open many blend files
created by random users, so the assurance those blend files wont run
arbitrary python code is something I'm glad to have.

Changing trusted defaults, communicating to user more clearly what
they do, adding option in header to reload-trusted, area all fine.
But I'd stop short of actually making decisions for users, eg, not
letting a script write to some location they would normally be allowed
to or limiting python functionality to the point useful operations are
disabled.

If we start turning off useful features it makes it a challenge for
script authors to workaround and knowing how CPython is designed they
will surely be able to do it without much effort. Then we just loose a
lot of dev time trying to secure something that is inherently
insecure.

Trying to sandbox python is more of a research project - perhaps we
can setup a state where pythons internals are temporarily disabled to
the point files cant be modified, or pre-process python bytecode and
disallow certain features, but I see this as a time sink - at that
point we probably should be asking ourselves why we use Python at all,
and not something like Lua or check on pypy which can be sand-boxed
apparently.


More information about the Bf-committers mailing list