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

[Benjamin Tolputt]

Charles Wardlaw wrote:
> But there's a difference between that and what Blender's currently  
> doing: that "security" feature is opt-in. Blender's is not, but in my  
> opinion should be.
>   

Again I come back to the user-base of the applications in question. How
many people do you know outside the graphics industry that have Maya
installed at home? How many of them have it installed (& hence licensed)
on multiple machines? I happen to know, right out of my personal
experience, three people that have Blender installed because they wanted
to play around - a legal secretary, an arborist, and a housewife who
wants to make 3D web-comics (but isn't quite there with the skills yet).

I believe that these casual users would make up a significant majority
of the downloads of Blender from the primary website. I have no real
statistics to back it up, of course, no-one does to the contrary either.
Ton could probably tell us how many downloads in total there are and,
even assuming everyone downloads it twice for some leeway, I don't think
the number of professional users would add up to 20% of that figure.

These casual users don't even KNOW what the option would mean and they
are the most likely ones to need it. They are not going to "opt-in" to
something they don't understand.

That said, these people are going to be just as frustrated when they
come across the limitations of the opt-in solution as Matt Ebb & Co are.
They'll download something off the web because it looks cool and either
will disable the option to get it to work (compromising their system) or
get ticked off that it doesn't work (which is likely for any armature
more complex than a basic reverse foot rig).

> I'm surprised that nobody has mentioned the simple solution of  
> disallowing automatic scripts and scripted constraints from accessing  
> the os and sys modules (perhaps limiting imports to only bpy). It'd be  
> easy enough to implement as a security measure by just scanning the  
> code or executing the code in a space where those modules were never  
> importable, but wouldn't break rigs.
>   

Because it is not possible. Look at the last security mailing frenzy on
this list and I think it was Campbell that showed a few ways around what
you suggest. As I have mentioned a couple of times now, Python is
designed to allow access to everything from everywhere. If it wasn't an
explicit desire when putting together the language, it sure as daylight
is a standard feature now and removing it is likely to cause some big
problems.

Python does not allow a single virtual machine to allow some parts of
code to run in a secure, module-limited subset of the execution context
(as would be needed to limit rig expressions to secure subsets) whilst
allowing other blocks of code to run relatively unsecured (like that
required for import / export plugins). It is a language limitation not
shared by many other languages, such as Lua, TinyScheme, Falcon &
others. The issue is a language limitation which would require major
changes to the Python VM code (and alot of testing of the Python
modules) to implement... whilst forever needing maintenance by Blender
developers as the Python development team has already stated they are
not interested in such sandboxing.