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

Benjamin Tolputt btolputt at internode.on.net
Wed Apr 28 11:36:55 CEST 2010


Daniel Salazar - 3Developer.com wrote:
> So the scenario here as I see it is: people who don't know about this
> leave the loading of scripts off (and are safe from the evil blender
> hackers out there), next people start having the problems related to
> this setting and due to it being unusable in production they find out
> how to disable it everywhere and then they are right where everything
> started, except from time to time someone forgets to set the flag on
> and gets a nice headache while wondering why this feature exists in
> the first place
>   

One could say the same about ActiveX plugins and a wide variety of other
security holes.

I hate to repeat myself but security is ALWAYS a trade-off. Logins
require remembering passwords, file systems have permissions restricting
access to files/directories, etc. In a perfect world one wouldn't need
to trade-off security against usability; but we live in the real world
and such trade-offs happen (& are accepted) all the time.

I think the core development team needs to decide whether security will
or will not be in Blender 2.5/2.6 because statements like the above are
creeping back into the "we don't need security" territory which I
thought was resolved. Either there is an accepted need/requirement for
security & it is included *or* the task of implementing security is
classified as unwanted/unimplementable at this time and it is removed.

It would be good to know where things stand because instead of "There is
a bug in the security code - fix the bug"; we seem to be getting "There
is a bug in the security feature - get rid of security".


More information about the Bf-committers mailing list