Matt Ebb wrote: > This stuff is unnecessary in a studio environment, Agreed. The primary target user-base for the security issue are new & inexperienced users who *will* download material online and install it without thinking about the consequences because they are simply unaware of them. Much like an email virus is targeted at the relatively computer illiterate.
I fully accept that there should be an option to turn this thing off completely and have that stick. I have similar "ignore this warning from now on" options in most the applications I put together. > But now we have this current situation designed to satisfy theoretical > concerns by people who may not have to deal with the practical > consequences. This is as theoretical a concern as macro virii which were ignored up until they did alot of damage to alot of poeple. I accept that Blender is a small target and that studios want the capability of controlling any & all security features affecting them (through being able to turn off any & all limitations should they desire to). I do not accept the fact that security is a theoretical problem or that only studios need to deal with consequences. > It won't really stop people from getting into trouble, > but instead *stops your own work in your own files from functioning*. > This is very frustrating and I think something has to change here On this, however, I agree 100%. The current "solution" to the problem is a half-assed solution at best and a hindrance almost all the time. This is not a fault of the developers really, but simply a consequence of Python lacking any real concept of process security. Basically, in choosing to use Python you have to accept the fact that you'll be using *all* of it, security holes and all. It is one of the /cons/ that go with the /pros/ of Python as an "embedded language" which, as the Python core team keep telling us, is not what it was designed for. I think a half-baked solution is worse than no solution at all. With no solution, the problem is more likely to be revisited when there is time and/or a possible answer. A half-baked solution does little to resolve the problem and, by it's very existence, hampers the need to put some real security options into the application. Hacks have a nasty habit of staying in a project for a long time, flawed and cumbersome as they may be, because they get "most of the job done". With security, you either get the job done properly or not at all, because half-solutions are non-solutions. -- Regards, Benjamin Tolputt Analyst Programmer _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
