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

[Remo Pini]

Hm...

To me - as a person coming from the IT security field - there seems to be an interesting conundrum:

At some point in the past, someone made the choice of using Python as the pervasive scripting language in Blender. We've all heard through various emails on how it is basically NOT possible to lock down Python to be secure (as well as being outside of the scope of actual language development according to the Python gurus, so it will never happen). At the same time, tons of stuff depends on Python being "fully" enabled, so shutting it off is not really an option as well.

From my experience, if an option needs to be turned on/off most of the time for things to work, it will be left at the most convenient setting always, so there really is no value in having the option in the first place.

From what I have read so far, the only "real" solution would be to move to a truly "sandboxable"/embeddable scripting language such as LUA, which is not going to happen or to keep running with the existing model of trusting everybody not to screw around with Python scripts.

All other solution that I have seen place an unmanageable burden on the user and usually require a central controlling entity (i.e. signed vs. unsigned code having access to restricted functions such as I/O).

We should keep this in perspective though. Most other 3D packages currently allow "dangerous" scripting too, so we don't really behave any worse by allowing scripts in the current setting than any other solution. Which is not to say that we shouldn't try to be "better" than the other packages on the long run...

Ultimately, I would suggest to abandon Python for a truly embedded scripting solution (i.e. LUA), but that would be a massive change with a huge impact... maybe worth a thought for Blender 3.0.

Cheers

Remo

> 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
> 
> > added -Y option to enable script execution, this means render nodes
> > don't need to have .B25.blend's
> >
> > eg.
> >  ./blender.bin -b -Y myblend.blend -a
> >
> >>  I have a history of lost work and time with this so called security
> >> features where blender decides to turn off drivers and ignore script links
> >> and so on and you don't notice it until you have worked on a faulty
> >> rig/scene for a long time or you have rendered some heavy frames and have to
> >> do it all over again. In 2.5 since the inclusion of the "trusted source"
> >> option this has done nothing but cause problems everywhere from teaching to
> >> every day jobs; students load rigs that don't work and naturally they do not
> >> know the difference, lost time with clients that in order to review a rig
> >> had to turn on the load py scripts option and they didn't knew about it so
> >> we all loose time, etc.
> >>
> >>  Today I sent a render to the farm and when it finished the character was
> >> all wrong.. so I spent a long time changing the .B25.blend files on all 17
> >> machines (boot with X session, change preference, reboot again). After all
> >> this I launch the render again and when it finished the problem is still
> >> there. It so happens that rendering from command line ignores the .B25.blend
> >> file... so not good. I had to export animation as MDD point cache and import
> >> back as RVKs in order to workaround the missing drivers
> >>
> >> http://www.pasteall.org/12745
> >>
> >>  So my point of view here is: stop playing around with my scene *please*,
> >> it's hard enough to get things working for blender to decide to break some
> >> random part. And this is the point of view of someone with 8 years of using
> >> blender almost every day, imagine someone new trying to figure out this
> >> problems?