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

Matt Ebb matt at mke3.net
Wed Apr 28 03:17:26 CEST 2010


On Wed, Apr 28, 2010 at 11:00 AM, Daniel Salazar - 3Developer.com
<zanqdo at gmail.com> wrote:

> In 2.5 since the inclusion of the "trusted source"
> option this has done nothing but cause problems everywhere

As I was mentioning with Daniel on IRC, I completely agree. These
'security' additions have always caused me more trouble than benefit
and I have had the same experiences at my studio in the past. For
example:

* People loading up files, animating and keying not knowing that
python constraints etc had decided to switch themselves off, meaning
that when they were enabled again, the animation was screwed

* Problems with render nodes on farms not enabling drivers/constraints
that you only notice once you get a several hour long render back from
the farm

This stuff is unnecessary in a studio environment, and costs money
directly in wasted time. To paraphrase what I said in IRC, the problem
is that this system is trying to solve a problem that a) hasn't
existed and b) doesn't actually solve anyway, while at the same time
it causing considerable trouble for people who are actually using
blender - the cost/benefit equation is way out of whack. There are
security risks for any kind of unverified file that you download - it
could be a python tool that you download, or for example look at the
amount of people who blindly download builds from graphicall.org which
could contain anything, or any other files from the internet either.

But now we have this current situation designed to satisfy theoretical
concerns by people who may not have to deal with the practical
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.

Matt


More information about the Bf-committers mailing list