6. Create a "secured blender" version of the installer (for platforms that support it) that creates a locked down blender user for executing blender. 7. Provide a downloadable virtual machine (VMWare/Virtual Box/etc.) image.
Martin Poirier wrote: > 0. Keep current features, switch from default on to default off. > > Martin > > --- On Thu, 4/29/10, Michael Judd <[email protected]> wrote: > > >> From: Michael Judd <[email protected]> >> Subject: Re: [Bf-committers] "Security" gets in the way >> To: "bf-blender developers" <[email protected]> >> Received: Thursday, April 29, 2010, 1:55 PM >> Hi guys, >> Is this the list of options? >> >> 1. Work with the python team to implement the desired >> security features >> into the python trunk. >> 2. Create a "secure" python fork and implement the desired >> security >> features into it. >> 3. Maintain a trusted/certified/signed repository of >> scripts and warn >> users when loading untrusted scripts. >> 4. Dump python and use something else. >> 5. Stick with the status quo. >> >> (1 or 2) and/or 3 make the most sense to me. >> 3 by itself seems the least amount of work and seems >> totally acceptable. >> Not that I'll be contributing anything other than my >> opinion. ;) >> Cheers! >> >> _______________________________________________ >> 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 > > -- Michael Judd 853 New Cleveland Rd Gumdale, Qld 4154 Email: [email protected] Phone: +61 (0)7 32452864 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
