[Bf-committers] Python sandbox
leif.a.andersen at gmail.com
Fri Mar 19 03:55:49 CET 2010
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.
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
More information about the Bf-committers