On Sun, Jun 9, 2013 at 12:15 AM, patrick boelens <[email protected]> wrote: >> 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.
I think you under estimate how easy it is to hide code in a blend file, at the risk of giving people bad ideas... - Add a driver some place the user wont see, (slow parent or so). - Make the driver exec() code stored in a fake-user, 3d-textblock which isn't visible in any 3d layer. - Then add some simple script which does something harmless/useful to allay user fear. > 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). Apparently they have exactly the same problem. > 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: [email protected] >> Date: Sat, 8 Jun 2013 13:23:26 +0200 >> To: [email protected] >> 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 - [email protected] - 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 <[email protected]> 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 - [email protected] - 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 <[email protected]> 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 - [email protected] - 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 <[email protected]> >> >> 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 - [email protected] - 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 >> >>>>>>> [email protected] >> >>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Bf-committers mailing list >> >>>>>> [email protected] >> >>>>>> 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 >> >>>>> [email protected] >> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >> >>>> >> >>>> _______________________________________________ >> >>>> Bf-committers mailing list >> >>>> [email protected] >> >>>> http://lists.blender.org/mailman/listinfo/bf-committers >> >>>> >> >>> _______________________________________________ >> >>> Bf-committers mailing list >> >>> [email protected] >> >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> >> _______________________________________________ >> >> Bf-committers mailing list >> >> [email protected] >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> > _______________________________________________ >> > Bf-committers mailing list >> > [email protected] >> > http://lists.blender.org/mailman/listinfo/bf-committers >> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
