On Thu, Jun 6, 2013 at 5:21 AM, Jace Priester <jacepries...@threespaceimaging.com> wrote: > Another +1 for not changing the OS module, or anything else for that > matter. I use lots of python system-related modules, including OS, in my > import/export/interop pipeline. If it is broken I will most likely not be > using blender anymore (seriously). > > Additionally, I don't believe security in blend files is an issue anyway. > If you have accepted a file from an untrusted source and opened it, YOU are > the security risk, not the program you opened it with. AVIs, DOCs, and > various other data files have had and still do have security risks > associated with them (whether internal scripts are allowed to run or not). > This problem is certainly not unique to blend files, and certainly not due > solely to the fact that blender allows python scripts to run. This is a > non-issue. > > The "Trusted Source" checkbox is a nice feature, I guess, but realistically > I've never used it because I want all blends to open and work as intended > by the creator. If I think it might be a malicious file, I don't accept it > in the first place. That's where security starts, and ultimately ends.
Developer working on the bug tracker you have to open many blend files created by random users, so the assurance those blend files wont run arbitrary python code is something I'm glad to have. Changing trusted defaults, communicating to user more clearly what they do, adding option in header to reload-trusted, area all fine. But I'd stop short of actually making decisions for users, eg, not letting a script write to some location they would normally be allowed to or limiting python functionality to the point useful operations are disabled. If we start turning off useful features it makes it a challenge for script authors to workaround and knowing how CPython is designed they will surely be able to do it without much effort. Then we just loose a lot of dev time trying to secure something that is inherently insecure. Trying to sandbox python is more of a research project - perhaps we can setup a state where pythons internals are temporarily disabled to the point files cant be modified, or pre-process python bytecode and disallow certain features, but I see this as a time sink - at that point we probably should be asking ourselves why we use Python at all, and not something like Lua or check on pypy which can be sand-boxed apparently. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers