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

[Ton Roosendaal]

Hi,

> I don't think I understand what you're saying here.

Sorry wasn't clear, I referred to auto-run of scripts. If a user installs an add-on, then it's at least a concious decision to use it. The source of add-on is known, and a user can decide to stick to official released ones. That's "secure" enough.

> I think the idea that you can somehow quickly reduce the problem to a
> useful subset of Python and the Blender API is flawed. 

I don't agree, for me 'security' here would mean at the same level we apply for our C code now. Better security then can be done step by step.

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 7 Jun, 2013, at 16:33, Brecht Van Lommel wrote:

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