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. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
