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

Erwin Coumans erwin.coumans at gmail.com
Fri Jun 7 18:49:14 CEST 2013 

>>Nearly every person who gets the menu "Do you want to run this script"
wouldn't know what to anwser.

I think you under-estimate Blender users.
People are familiar with such a question, for example when using a web
browser. I think it is good to give the user control.



On 7 June 2013 09:26, Ton Roosendaal <ton at blender.org> wrote:

> Hi,
>
> Making autorun default off (and optional) is really a good start. But it's
> not enough. Especially requesters won't work well. Nearly every person who
> gets the menu "Do you want to run this script" wouldn't know what to anwser.
>
> It's like a click on "I agreed with the license". Only lawyers are
> interested in such - it moves liability to the user. Bad practice.
>
> -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 18:15, Erwin Coumans wrote:
>
> > I just want Blender to ask me at loading time, if I want to run scripts
> or
> > not. Obviously option should be a user preference.
> >
> > At loading time you can then reply:
> >
> > 1) run script this time
> > 2) don't run scripts this time
> > 3) always run scripts and don't nag/ask me ever again
> > 4) never run scripts and don't nag/ask me ever again
> >
> > That is a very simple starting point to better manage security I think.
> > Thanks,
> > Erwin
> >
> >
> >
> >
> >
> > On 7 June 2013 09:03, Ton Roosendaal <ton at blender.org> wrote:
> >
> >> Hi Shrinidhi,
> >>
> >>> Why not have a script that ships with blender, which can be run
> >>> individually,  which checks the blender file for scripts  and informs
> the
> >>> user if it is malicious or safe ?
> >>
> >> That's interesting to check, but I don't like to make users responsible
> >> for checking each .blend they want to load. My preference is a way
> that's
> >> relatively safe and works out of the box for everyone (except system
> >> administrators :).
> >>
> >>> 1 : Changing blenders default behavior for running scripts is like
> >> killing
> >>> a few scripters in studios using blender.
> >>
> >> That is only true if we stick to how it works now. We can find ways to
> >> either force scripts to become add-ons or to mark .blend files or
> scripts
> >> as trusted for own use and studios.
> >>
> >> -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:37, Shrinidhi Rao wrote:
> >>
> >>> On Fri, Jun 7, 2013 at 4:42 PM, Ton Roosendaal <ton at blender.org>
> wrote:
> >>>
> >>>> Hi all Pythoneers,
> >>>>
> >>>> Scripters are important for Blender, but just like the C developers
> they
> >>>> have a responsibility for users out there. A good proposal for
> security
> >> has
> >>>> to come from you as experts first.
> >>>>
> >>>
> >>> Why not have a script that ships with blender, which can be run
> >>> individually,  which checks the blender file for scripts  and informs
> the
> >>> user if it is malicious or safe ?
> >>> The script can have a way to update a set of rules that marks the files
> >>> safe or unsafe. May be blender institute can maintain a database and
> the
> >>> script will auto-update the rules.
> >>> People responsible for the python API can keep updating the database
> >>> incrementally.
> >>>
> >>> Now why a different script? .
> >>> 1 : Changing blenders default behavior for running scripts is like
> >> killing
> >>> a few scripters in studios using blender.
> >>> 2 : it can be run individually by the security conscious people . at
> >> least
> >>> they will have a way to check if a blend file is evil or good .
> >>> 3: for large deployments it can be run in batch mode to check multiple
> >>> files at once .
> >>>
> >>>
> >>> This way we can make the users happy . at least they will have a way to
> >>> tell what the blend file is up to .
> >>> In a studio we need not worry about it as there are proper user
> >> permissions
> >>> and policies already implemented.
> >>>
> >>>
> >>>
> >>>>
> >>>> If this discussion just leads to marking every idea as impossible
> >> (Python
> >>>> is insecure by design) then we should have a big problem with keeping
> >>>> Python in Blender. Fork it, sandbox it, or move to LUA.
> >>>>
> >>>> This is not at all constructive! .
> >>> Arguing against using python and replacing it with a crippled scripting
> >>> language is as good as telling professional studios users to stop using
> >>> blender directly. it will not help blender in anyway. first thing they
> >> see
> >>> is how can data be interchanged between softwares . no studio will dump
> >>> their existing softwares and start using blender entirely for all their
> >>> production stages . blender should be able to communicate with other
> >>> software and a restricted scripting language will not help blender or
> its
> >>> users.
> >>>
> >>> as it is, i am already feeling crippled without a socket based command
> >> port
> >>> in blender . there is no way to send a command to blender like opening
> >>> files, linking etc! . well . this is not needed if we have only a
> blender
> >>> specific pipeline. but if we want to keep our pipeline UI out of
> blender
> >>> then its very useful
> >>>
> >>>
> >>>
> >>>> Let it be clear: we're making Blender here, which is meant to be a 3D
> >>>> creation tool. It's not a Python development environment. Users come
> >> first,
> >>>> scripters and coders second. So... stop being smartasses and think
> >>>> constructive a bit.
> >>>>
> >>>>
> >>> A 3D creation tool without a powerfull scripting api is useless
> nowadays,
> >>> at least for professional users.
> >>> Users come first . yes.. i totally agree with you . but the users
> always
> >>> improve and always want more out the software once they become aware
> that
> >>> they can do certain things in blender . And the same users who wanted
> too
> >>> much security will be annoyed by the same security measures once they
> >> come
> >>> out of their hobbyist attitude and become scripters and coders.
> >>>
> >>>
> >>>
> >>>> -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 12:08, Domino Marama wrote:
> >>>>
> >>>>> On 06/07/2013 10:21 AM, Ton Roosendaal wrote:
> >>>>>> Hi Campbell,
> >>>>>>
> >>>>>> I don't know enough about Python internals, so I depend on someone
> to
> >>>> help designing a sane way to handle security risks here. There must be
> >> ways
> >>>> we can help users?
> >>>>>>
> >>>>>> Look for example at the standard UI scripts. Apart from 1 case,
> >> there's
> >>>> no "import os" anywhere. Same goes for essential scripts riggers or
> >>>> animators use.
> >>>>>>
> >>>>>> So, why not add a provision in Blender code to check on such cases.
> >>>> Just don't allow import of any module = safe script? In all other
> cases:
> >>>> needs to be explicitly permitted to run.
> >>>>>>
> >>>>>> Something like this would make a "trusted source" option on file
> >>>> loading more useful. Right now, unticking "trusted source" is almost
> >>>> equivalent to "disable useful features".
> >>>>>>
> >>>>>>
> >>>>>>>> oh = 'SOS HELP!'
> >>>>>>>> ohoh = __import__(oh[1:3].lower())
> >>>>>>>> ohoh
> >>>>> <module 'os' from
> >>>>>
> >>>>
> >>
> '/home/domino/Applications/blender-2.67-linux-glibc211-x86_64/2.67/python/lib/python3.3/os.py'>
> >>>>>
> >>>>> On Linux distros where system Python is used, I doubt anything can be
> >>>>> done to prevent the import function from being used.
> >>>>>
> >>>>> Load Blender with a console, check there's the startup message on it.
> >>>>> Then paste this into say the frame number field..
> >>>>>
> >>>>> eval("__import__('os').system('clear')", {})
> >>>>>
> >>>>> Now check console again.. Just checking scripts for imports isn't
> >> enough.
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> regards
> >>> - shrinidhi
> >>>
> >>>
> >>> Even god fails to understand a human until his death!
> >>> http://www.linkedin.com/in/shrinidhi666
> >>> https://github.com/shrinidhi666
> >>>
> >>>
> >>>
> >>> <http://www.imdb.com/name/nm3025616>
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

More information about the Bf-committers mailing list