[Bf-committers] Python sandbox
ideasman42 at gmail.com
Fri Mar 19 10:36:53 CET 2010
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.
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
> 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
>> 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
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers