Hi, > I don't think I understand what you're saying here.
Sorry wasn't clear, I referred to auto-run of scripts. If a user installs an add-on, then it's at least a concious decision to use it. The source of add-on is known, and a user can decide to stick to official released ones. That's "secure" enough. > I think the idea that you can somehow quickly reduce the problem to a > useful subset of Python and the Blender API is flawed. I don't agree, for me 'security' here would mean at the same level we apply for our C code now. Better security then can be done step by step. -Ton- -------------------------------------------------------- Ton Roosendaal - [email protected] - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 7 Jun, 2013, at 16:33, Brecht Van Lommel wrote: > On Fri, Jun 7, 2013 at 4:02 PM, Ton Roosendaal <[email protected]> wrote: >>> If you want security by default then my suggestion is to just disable >>> scripts by default on load. If the .blend file contains a script the >>> info header can show a warning and button to reload the .blend file >>> with scripts enabled. >> >> Sounds OK - I also need to know how this works for add-ons then. If our >> standard is to have scripts require this registration as add-on first, we >> have a built-in security as well. Activate once, then use. > > In order to declare a python script safe we need a trusted developer > to approve it manually. I think that's what the bf-extensions > repository is for, addons that are there can be considered secure? But > I don't think I understand what you're saying here. > > It does not seem to be particularly useful to me to distinguish > between secure and insecure addons not in our repository, as maybe > half of them need disk access anyway. > >>> Realistically I think Python and the Blender Python API are just >>> insecure, and that securing them is not feasible. We could however >>> make it difficult enough to do this that only an expert could make >>> malicious .blend files. That does mean we need to fork Python, create >>> a sandbox implementation for Python 3.0, and audit the entire API for >>> security issues, and then create a system where we make a distinction >>> between secure and insecure scripts (as the latter will always be >>> needed for some cases). I expect that would take 6-12 months of >>> development time, along with continued work maintaining our own Python >>> fork and keeping the BPY API secure. >> >> This development should be done by Python.org then. Blender is not the only >> Python embedded project who would love to see attention for such topics. >> A year of development time would be feasible to organize sponsoring for. >> Autodesk hint hint! >> >> Besides that - I think you make a logical mistake in the reasoning. We don't >> need to make a complete secure Python for everything. We just want safe ways >> of running scripts in Blender. Reduce the problem first, then tackle it. And >> then - in the end - check on how to enable adminstrators to manage their >> harddrives. > > I think the idea that you can somehow quickly reduce the problem to a > useful subset of Python and the Blender API is flawed. If you disable > anything that's potentially insecure you're not left with much, as > calling operators, changing keybindings, add/replacing buttons in the > UI, driver setups, editing user preferences, creating modifiers and > nodes that write to disk, ... can all be exploited. I think it will > take a bunch of time to make those secure one by one before you'd be > able to write useful secure scripts again. > > Brecht. > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
