Is any of this a problem in practice? What do other applications do? Seems to me we might be making this too complicated. Just have a "warning: this .blend has scripts, which can be dangerous if you don't trust the author; enable scripts?" popup on loading .blends.
For something as complex as a digital art production package, I think it's ok to treat .blends as if they *are* .exe's, and warn users appropriately. Joe On Fri, Mar 19, 2010 at 2:36 AM, Campbell Barton <ideasma...@gmail.com> wrote: > Hi Leif, probably repeating myself here but I don't understand the > rationale for some of your suggestions. > - Secure+Updated script installation doesn't help much since blend > files themselves can include auto-executing drivers. > - Separate python doesn't help with security, unless its separated in > such a way blender can run without python at all. but in that case > they also wont get a user interface so... don't think this helps > either unless we move the UI back into C. > > Agree patching python would be a pain. > > This is an interesting sandbox project but I dont think blender can > use since we would need to switch trusted/untrused context a lot but > since the topic is raised worth mentioning. > > http://github.com/haypo/pysandbox/tree/master/sandbox/ > It works by writing into CPythons memory with ctypes to disable > certain aspects of python. > > > On Fri, Mar 19, 2010 at 3:55 AM, Leif Andersen > <leif.a.ander...@gmail.com> wrote: >> As sad as it is, it seams like your axiom Jonathan, has been true. >> Although, that is based only on empirical evidence, not an actual rigorous >> proof. (i.e., I would die happy if I ever found a way to make a computer be >> secure, and work seamlessly). Some examples of this are the previous emails >> in this thread, about people who have had trouble with a locked down python. >> >> I still think though (like the first email in this thread), that it would be >> better to keep python separate, but still make sure that it has been >> included on the system. We could also have a script that checks to make >> sure it is still the latest version, in an attempt to keep it secure. If we >> include python directly into blender, that would add a severe amount of >> overhead to ensure that blender keeps up with the latest build of python, >> and even worse, if we customize it with patches, we would have to constantly >> repatch it, work that would be better spend fixing bugs/other flaws unique >> to blender/adding new features.Than again, on the other hand, we may have to >> still do the same thing if we try to customize a separate python build. >> >> Than again, all of this is at a very hand wavy level. And my arguments seem >> to me consist of me waving my arms, and claiming I can fly. :) >> >> Anyway, thank you for the support thus far everyone. >> >> ~Leif Andersen >> >> ---------- >> So Much to Learn, Such Little Time >> http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/ >> >> >> On Thu, Mar 18, 2010 at 12:43, Mike Belanger >> <mikejamesbelan...@gmail.com>wrote: >> >>> To me its not a question of how secure your pipeline is, but how quickly >>> you >>> can 'bounce back' after a system failure, maliciously-motived or otherwise. >>> Yeah, you should have a firewall, passwords, admin rights etc. But really, >>> the best insurance policy for studio assets is automated-backup. >>> If anything, this sandbox thing almost sounds like it could restrict >>> backups, or make them difficult/require consent every save. Anything >>> discouraging/inhibiting backup is a far bigger threat, imho. >>> >>> A disclaimer in front of AddOns works for me. >>> >>> >>> On Wed, Mar 17, 2010 at 11:28 PM, Matt Ebb <m...@mke3.net> wrote: >>> >>> > >>> > On 18/03/2010, at 15:09 , §ĥřïñïďĥï Ŗäö wrote: >>> > >>> > > Hi, >>> > > This is my very first mail to this list . I am not a developer but I >>> > > thought >>> > > i will put my 2 cents here since I felt that this discussion is a >>> > > waste of >>> > > time for many reasons . >>> > > 1: +100 for Brecth and his opinion (He is perfectly right !!) >>> > > 2: sanboxing blender will make it unusable in large pipelines where >>> > > we need >>> > > blender to be integrated with other softwares and also need to do a >>> > > lot of >>> > > automatic IO (this includes IO to databases and in renderfarm too >>> > > which can >>> > > be used for other than just rendering out images ) >>> > >>> > +1 to this too. Even in 2.4* we had lots of trouble at our studio with >>> > scriptlinks, pydrivers, etc being off by default. We had problems (and >>> > wasted hours of work) when an artist took work home, installed a >>> > default blender from online and worked with that - getting the file >>> > into a state that caused lots of problems when the scripts were >>> > working as intended. This may have happened more than once too, can't >>> > remember. Similar trouble when doing some complicated things and >>> > sending files out to other studios who weren't familiar with Blender >>> > and this particular issue that really doesn't affect them. >>> > >>> > Many people who use blender don't download and open files from >>> > strangers on the web, and I would not like to see practical usability >>> > hindered just to try and give people who do the impression of security. >>> > >>> > cheers, >>> > >>> > Matt >>> > _______________________________________________ >>> > Bf-committers mailing list >>> > Bf-committers@blender.org >>> > http://lists.blender.org/mailman/listinfo/bf-committers >>> > >>> >>> >>> >>> -- >>> www.watchmike.ca >>> _______________________________________________ >>> 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 >> > > > > -- > - Campbell > _______________________________________________ > 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