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

Brecht Van Lommel brechtvanlommel at pandora.be
Fri Jun 7 16:33:34 CEST 2013


On Fri, Jun 7, 2013 at 4:02 PM, Ton Roosendaal <ton at blender.org> wrote:
>> If you want security by default then my suggestion is to just disable
>> scripts by default on load. If the .blend file contains a script the
>> info header can show a warning and button to reload the .blend file
>> with scripts enabled.
>
> Sounds OK - I also need to know how this works for add-ons then. If our standard is to have scripts require this registration as add-on first, we have a built-in security as well. Activate once, then use.

In order to declare a python script safe we need a trusted developer
to approve it manually. I think that's what the bf-extensions
repository is for, addons that are there can be considered secure? But
I don't think I understand what you're saying here.

It does not seem to be particularly useful to me to distinguish
between secure and insecure addons not in our repository, as maybe
half of them need disk access anyway.

>> Realistically I think Python and the Blender Python API are just
>> insecure, and that securing them is not feasible. We could however
>> make it difficult enough to do this that only an expert could make
>> malicious .blend files. That does mean we need to fork Python, create
>> a sandbox implementation for Python 3.0, and audit the entire API for
>> security issues, and then create a system where we make a distinction
>> between secure and insecure scripts (as the latter will always be
>> needed for some cases). I expect that would take 6-12 months of
>> development time, along with continued work maintaining our own Python
>> fork and keeping the BPY API secure.
>
> This development should be done by Python.org then. Blender is not the only Python embedded project who would love to see attention for such topics.
> A year of development time would be feasible to organize sponsoring for. Autodesk hint hint!
>
> Besides that - I think you make a logical mistake in the reasoning. We don't need to make a complete secure Python for everything. We just want safe ways of running scripts in Blender. Reduce the problem first, then tackle it. And then - in the end - check on how to enable adminstrators to manage their harddrives.

I think the idea that you can somehow quickly reduce the problem to a
useful subset of Python and the Blender API is flawed. If you disable
anything that's potentially insecure you're not left with much, as
calling operators, changing keybindings, add/replacing buttons in the
UI, driver setups, editing user preferences, creating modifiers and
nodes that write to disk, ... can all be exploited. I think it will
take a bunch of time to make those secure one by one before you'd be
able to write useful secure scripts again.

Brecht.


More information about the Bf-committers mailing list