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

[Bassam Kurdali]

On Wed, 2013-06-05 at 14:35 +0200, Ton Roosendaal wrote:
> Hi,
> 
> Here's just some ideas to investigate:
> 
> 1) Better location for temp saves

1) is actually really nice, /tmp has issues on some systems still and we
often move the default to inside the home dir. esp. some systems don't
keep /tmp between boots which has caused data loss sometimes.

> 2) Communicate to users all saving C/C++ code well
> 
saves initiated by a user (not by a script, tool, autosave or node save)
should probably allowed anywhere the user has permission. also the user
should have an easy way to make a file trusted.

> 3) Formalize definition of "trusted source" better.
> 
> - Any .blend file with absolute output paths could be marked untrusted by default.
> 
> - Macs (and Windows?) already have a way to detect a downloaded file, which can marked to be untrusted .blend.
> 
> - Blender files can also get a User identifier struct, which can be used for various ways to mark files 'trusted' or not. 
> In its simplest implementation it can just store an identifier string (copied from userpref) to mark files as "saved by myself". 
> 
Once you get into this the trusted thing can be forged; I'm guessing
some cyptography / security people have to weigh in on how to stop that.
> 4) Replace Python's os module
> 
Please don't!
We use python OS module so much for pipeline scripts, and I can't
imagine other studios just don't do this. Replacing it with something
crippled for security would be a huge annoyance - yes we can build our
own, but for us at least we depend on external collaborators running on
their own systems - sometimes our builds don't work for them. Things
that we need to do are in the file manipulation range, such as moving or
renaming large numbers of files, we access our share for the project in
an absolute path in the root (this was standard practice before I got
here) etc. etc. Messing with OS module would be pretty bad for us, and I
don't know what would make it safe other than removing most of it's
functionality anyway (the only thing safe is probably file path
joining/splitting)
> -Ton-
> 
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> 
> 
> 
> On 5 Jun, 2013, at 13:24, Ton Roosendaal wrote:
> 
> > Hi,
> > 
> > I've checked some history of past discussions (including sandboxing Python) and to me it seems we still accept too much risk here. As a team (and for me as Blender Foundation chairman) I feel it's a big responsibility to not waive away so easily.
> > 
> > More over - it's a disaster waiting to be happening one day. It would be unforgivable if we didn't at least help users to have a basic security in place.
> > 
> > The discussion is also getting too much complicated by knowledgable people who point out that there's always another vulnerability or other methods to bypass any security feature. IMHO that's irrelevant, should never be a reason to ignore it altogether.
> > 
> > We should be able to bring down this topic to a basic and sensible minimal protection we provide for users.
> > 
> > Can we form some kindof workgroup to investigate it further and define a proposal for actions? Or a roadmap? 
> > 
> > And: is there a consensis to make the default startup install have 'autorun' disabled, with a notifier in the top header about it?
> > 
> > -Ton-
> > 
> > --------------------------------------------------------
> > Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> > Chairman Blender Foundation - Producer Blender Institute
> > Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> > 
> > 
> > 
> > On 5 Jun, 2013, at 8:25, Campbell Barton wrote:
> > 
> >> On Wed, Jun 5, 2013 at 4:21 PM, Knapp <magick.crow at gmail.com> wrote:
> >>> On Wed, Jun 5, 2013 at 8:03 AM, Knapp <magick.crow at gmail.com> wrote:
> >>>> As a normal hobby users, the biggest risk that I see is downloading a
> >>>> blend from the net and opening it. This is not something we are likely
> >>>> to give up. So, warning or not, what good is it? I need some way to
> >>>> know if the file is good or bad. I don't see an answer. I would say a
> >>>> good third of the users or more download blends for learning at least
> >>>> and often for producing their own stuff.
> >>> 
> >>> What might be much more useful is a program that load a blend and tell
> >>> me what it might do. For example, does it run scripts, does it have
> >>> crazy large data sets? If it runs scripts then it should be able to
> >>> show me them. It should look at the data sizes that the blend will use
> >>> and make guesses if it is too large. Naturally it should only open the
> >>> blend as data and not as blender would.
> >>> --
> >>> Douglas E Knapp
> >> 
> >> Such a tool isn't so hard to write, see this python module which loads
> >> up blend files without using blender.
> >> http://blender-aid.googlecode.com/svn/trunk/src/blendfile.py
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> > 
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers