> > I cannot speak for the community, but my thoughts are that a "web of > trust" misses the point. Trust systems work so long as one assumes that > the participants are going to be a somewhat insular community. This > works well for code, emails, and the like but artists? We're doing > incredibly our
best to shield them from the technicalities on the one hand, but > requiring them to be part of a trust network just to share files? > True, while I don't completely agree with the exact method Jonathon is proposing, I still think the idea of a plugin center of sorts is a good idea. It seams like blender prides itself on having an incredibly small system requirements, and download size for what it does (after all, other 3d modeling programs takes up hundreds of MB, if not several GB of data, and it also runs on relatively little ram (for small enough projects anyway)). If all of the main plugins were stored in the blender file, with blender 2.5+ allowing for very modular programing, that could get unneeded large. On the other hand, if the plugins are stored in a location buried deep within the blender website/wiki/other blender community page, the user would have to open their browser, go to that page, find the script they wanted, download it, either put it in a plugins directory, or run a script to automatically put it in the directory (both of which are going to be incredibly insecure, no matter how much you sandbox python (well, unless you limited it to only allow for a few functions that don't use indirection in any way shape or form)), or the user would open up blender, click on an add plugin button, a security warning would pop up, the user would then locate the file on his hard drive, and the plugin would get added. You could also potentially have multiple levels of access, for example, a plugin that only allows for a customized window wouldn't need access to the hard drive, only to a few 'button and menu objects', although, passing in the context could provide major security flaws. On the other hand, there could be a button in blender, that opens up a dialog, which contains a software center, containing all of the pseudo social aspects that plugin managers (such as the one in the wordpress software), has. Also, you could potentially either 'crowd source' (I hate that phrase, if anyone has anything better, please tell me) the plugins (the best way would likely to be to only allow for apps who's source code is viewable, and/or to have a digg like review system), or, the default could only be to show plugins that the blender foundation has personally verified (which I think isn't necessarily the best way, but it would work for a few plugins). The user then clicks on the icon, sees a security warning, with a link showing how the plugin center approves software, and then they can download it. Alternatively, if the user did find a plugin that they liked on an external website, they could add it (either by a seperit button outside of the center, or by an 'add from external link' button, this would of course, pop up with a more fervent security warning. ~Leif Andersen ---------- So Much to Learn, Such Little Time http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/ On Wed, Mar 17, 2010 at 19:45, Brecht Van Lommel <bre...@blender.org> wrote: > Hi, > > On Thu, Mar 18, 2010 at 1:51 AM, Benjamin Tolputt > <btolp...@internode.on.net> wrote: > >> To sum up my opinion, sandboxing is very hard and not something we can > >> solve once, it requires continuous attention, so let's not even try > >> it. Instead, the install addon operator should warn about security > >> problems, and loading a .blend file with scripts should become easier > >> for users. > >> > > > > Actually, sand-boxing scripts is quite easy provided you use a platform > > that supports it. Python currently does not support this so the task > > seems insurmountable; but only so long as you look through the Python > > lens. It is quite simple to sandbox applications using Lua - simply > > don't give them access to the unsecure functionality. If you don't want > > the user reading/writing files not explicitly handed to them? Then don't > > give them access to the "io" library (by excluding it from the VM's > > initialisation). Don't want to give the person access to the operating > > system, don't add the "os" module to those accessible by the VM. And so > on. > > I don't think making the Blender API safe is easy. Some examples of > things that could be exploited: > * .blend/image/sound save operators > * render animation operator > * physics systems point caches writing to disk > * open file browser + run file delete operator > * binding keymap or buttons to an operator > * compositing file output node > * register operator to override .obj exporter > > And then there are of course the more complicated ones, memory > corruption, buffer overruns, etc now become security issues. I bet you > can find dozens of indirect an non-obvious ways to do damage. Now, you > can try to figure out all those cases and add checks for them, but > doing this well is really hard. Security issues in web browsers don't > happen because they forgot to disable access to the IO module. And as > new features are added to Blender this does require continuous > attention. > > Brecht. > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers