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 <[email protected]> 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 > <[email protected]>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 <[email protected]> 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 >> > [email protected] >> > http://lists.blender.org/mailman/listinfo/bf-committers >> > >> >> >> >> -- >> www.watchmike.ca >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
