> I consider such requests totally void of any meaning, because you
simply have no way to find out what the consequences are of accepting
the choice. If you don't accept it you cannot even use the .blend file
nor use the DVD you paid for.
I may be missing the obvious here, but I would imagine the typical use of this
pop-up to go as follows:
- Download potentially unsafe .blend.
- Open file, get prompted
- Choose to not run the scripts
- Inspect included scripts in Text Blocks (add-ons have already been manually
installed and thus approved by the user)
- Reload the file with scripts enabled (or better yet: run the blocked scripts
without reloading) if I conclude the scripts are safe.
Sure, not everyone's a programmer that can inspect the scripts, but at some
point I feel the responsibility lies with the users and with the sites offering
the .blends to inform them of potential dangers, and not so much with the BF
trying to create a super-safe environment. Super-safe in this case translating
to crippled or unusable for some.
There's nothing wrong with wanting to do a pre-emptive strike, but some of the
measures mentioned are taking it too far IMHO. How do other 3D suites with
embedded scripting handle this? Somehow I feel we're overthinking a problem
that isn't really a problem (yet).
I think the User Preference, along with an additional one to judge on a
case-by-case basis would have the best trade-off between being inobtrusive and
providing users with an additional layer of control and security.
Just my two cents,
Patrick
> From: t...@blender.org
> Date: Sat, 8 Jun 2013 13:23:26 +0200
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] Please turn off Auto Run Python Scripts by
> default
>
> Hi Erwin,
>
> Put yourself in the position of someone who purchases the famous CGcookie
> animation training DVD. On loading the first tutorial file, Blender then
> throws a popup:
>
> "This .blend file contains autorun scripts, do you want to run it?"
>
> I consider such requests totally void of any meaning, because you simply have
> no way to find out what the consequences are of accepting the choice. If you
> don't accept it you cannot even use the .blend file nor use the DVD you paid
> for.
>
> This is not user control, it's blaming users for trying to get a working
> product.
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands
>
>
>
> On 7 Jun, 2013, at 18:49, Erwin Coumans wrote:
>
> >>> 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 <t...@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 - t...@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 <t...@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 - t...@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 <t...@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 - t...@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@blender.org
> >>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Bf-committers mailing list
> >>>>>> Bf-committers@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@blender.org
> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>>
> >>>> _______________________________________________
> >>>> Bf-committers mailing list
> >>>> Bf-committers@blender.org
> >>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>>
> >>> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers@blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
