[Bf-committers] "Security" gets in the way

[Benjamin Tolputt]

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