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
