Hi Jace, I am not talking about your use case. You should be able to code whatever you like.
However, when it comes to the binaries and software we release for everyone, I expect developers to accept some responsibilities here. We try to keep up with a high standard for C/C++ developers for Blender, and same would go for Python scripts we bundle with, and especially for how we provide facilities for running scripts for users who don't code Python. -Ton- -------------------------------------------------------- Ton Roosendaal - [email protected] - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 5 Jun, 2013, at 21:21, Jace Priester 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. > > > On Wed, Jun 5, 2013 at 10:55 AM, Campbell Barton <[email protected]>wrote: > >> Hacked os module isn't really an option, Python uses this for its >> internal operations all over the place - a lot of python modules are >> written in Python so these would break. >> >> In python3.3 module dir... >> find -name "*.py" | xargs grep "\bos\." | wc -l >> --> 7833 >> >> Attempting to let Python do its own thing but sandbox Blender scripts >> also cant work well, >> >> In the BGE we did have some basic security (disable some modules & >> open()... iirc), >> But this is trivially easy to workaround - as in one line of python to >> get access to the real modules/functions. >> >> The only way I could see this working would be to do this on a libc >> level - replacing pythons own calls to open() / fopen() etc. But this >> also gives high risk of breaking Python its self. >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > > > -------------------------------------------------------------------------- > Jace Priester > Threespace Imaging > [email protected] > 559-284-0904 > -------------------------------------------------------------------------- > _______________________________________________ > 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
