> , there needs to be a way of recuperating > > ~Leif Andersen Load your most recent backup files, assuming your entire project has been erased.
Mike Belanger ( Mikahl ) www.watchmike.ca > > > ---------- > 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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers