[Bf-committers] Python sandbox

Tue Mar 23 02:24:30 CET 2010

> , 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 <joeedh at 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 <ideasman42 at 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.andersen at 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 <
>> mikejamesbelanger at 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 <matt at 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 at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> www.watchmike.ca
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>> 
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> - Campbell
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers