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

Benjamin Tolputt btolputt at internode.on.net
Fri Jun 7 01:04:49 CEST 2013


On 07/06/2013, at 4:13 AM, Campbell Barton wrote:

> On Thu, Jun 6, 2013 at 6:47 PM, Ton Roosendaal <ton at blender.org> wrote:
>> Hi,
>> 
>> I think you give up too easily here. :) For example, we could also make a bpy.os module, and mark scripts that use this as 'trusted'. Scripts using the os.module itself then require a user to explicitly run it, or being embedded in a file marked trusted (own files etc).
> 
> You know I already attempted this and have been shown by developers
> more expert in CPython internals then me, that CPython makes not
> effort to support such limitations and that is trivial to workaround
> them.
> 
> You assume there is an effective way to control module importing (that
> we could even stop a script from using any of CPythons bundled modules
> - `os` included).
> 
> I'd want good evidence this can be done, until someone shows this -
> I'll assume it can't.

I'm one of the folks who originally agitated for a more secure Blender last time this subject came up and, much as I hate to say it, Campbell has a point. Python is insecure by design. It is a consequence of Python's "don't embed, extend" mindset that has guided their development for over a decade. It sucks and wouldn't have happened if a scripting language designed for embedding (like Lua, AngelScript, etc) had been chosen upfront, but we're well beyond the point of choosing a more secure language - Python is the language behind Blender and we have to deal with the situation as it stands.

With that acknowledgement in mind, I don't see a good argument against disabling Python when opening blend file by default (with warning in the header). Yes, I acknowledge that as soon as any Python code in the file is run (be it in a driver, in an autorun text block, whatever), you have breached whatever security Blender can provide and all the Python libraries are now accessible to the untrusted blend file, but there is nothing to say we HAVE to run those Python snippets automatically. Why is there such pressure against the ability to, as a UI accessible option, have blend files load without running their Python drivers, text blocks, etc automatically?

Macros in Microsoft's Office have the same problems we do (once you allow them to run, they can own your system) and they solve it through the very simple mechanism of informing and allowing the user not to run said macros on loading. If the modal dialog UI concept is not going to be allowed in Blender, then the next best thing is to load with Python script (from the blend) disabled by default with a clear warning/message indicating such. Just because perfect security is beyond the reach of a script-enabled, Python-based application doesn't mean we should reject the low hanging fruit of enabling users to decide whether they want to run embedded scripts or not.

--
Benjamin Tolputt
Bent Solutions Pty Ltd


More information about the Bf-committers mailing list