Joe; Yes, but on the off chance that the user does add a malicious .blend file? As was said earlier in this thread, there needs to be a way of recuperating from it, if at all possible. Putting a pop up only solves half of the problem. (Then again, I think providing a good way to recuperate will only solve half of the remaining half of the problem).
~Leif Andersen ---------- So Much to Learn, Such Little Time http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/ On Mon, Mar 22, 2010 at 17:53, joe <joe...@gmail.com> wrote: > 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 > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers