[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