Hi, > Things > that we need to do are in the file manipulation range, such as moving or > renaming large numbers of files
Well, that you can do outside Blender via regular Python too? Further - if we can make file manipulations in the UI work sane/safe (and usable still), the hacked os module would just do same :) You will also define your own blends to be 'trusted' and allow scripts there to write anywhere you want (or not). -Ton- -------------------------------------------------------- Ton Roosendaal - [email protected] - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 5 Jun, 2013, at 16:19, Bassam Kurdali wrote: > On Wed, 2013-06-05 at 14:35 +0200, Ton Roosendaal wrote: >> Hi, >> >> Here's just some ideas to investigate: >> >> 1) Better location for temp saves > > 1) is actually really nice, /tmp has issues on some systems still and we > often move the default to inside the home dir. esp. some systems don't > keep /tmp between boots which has caused data loss sometimes. > >> 2) Communicate to users all saving C/C++ code well >> > saves initiated by a user (not by a script, tool, autosave or node save) > should probably allowed anywhere the user has permission. also the user > should have an easy way to make a file trusted. > >> 3) Formalize definition of "trusted source" better. >> >> - Any .blend file with absolute output paths could be marked untrusted by >> default. >> >> - Macs (and Windows?) already have a way to detect a downloaded file, which >> can marked to be untrusted .blend. >> >> - Blender files can also get a User identifier struct, which can be used for >> various ways to mark files 'trusted' or not. >> In its simplest implementation it can just store an identifier string >> (copied from userpref) to mark files as "saved by myself". >> > Once you get into this the trusted thing can be forged; I'm guessing > some cyptography / security people have to weigh in on how to stop that. >> 4) Replace Python's os module >> > Please don't! > We use python OS module so much for pipeline scripts, and I can't > imagine other studios just don't do this. Replacing it with something > crippled for security would be a huge annoyance - yes we can build our > own, but for us at least we depend on external collaborators running on > their own systems - sometimes our builds don't work for them. Things > that we need to do are in the file manipulation range, such as moving or > renaming large numbers of files, we access our share for the project in > an absolute path in the root (this was standard practice before I got > here) etc. etc. Messing with OS module would be pretty bad for us, and I > don't know what would make it safe other than removing most of it's > functionality anyway (the only thing safe is probably file path > joining/splitting) >> -Ton- >> >> -------------------------------------------------------- >> Ton Roosendaal - [email protected] - www.blender.org >> Chairman Blender Foundation - Producer Blender Institute >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >> >> >> >> On 5 Jun, 2013, at 13:24, Ton Roosendaal wrote: >> >>> Hi, >>> >>> I've checked some history of past discussions (including sandboxing Python) >>> and to me it seems we still accept too much risk here. As a team (and for >>> me as Blender Foundation chairman) I feel it's a big responsibility to not >>> waive away so easily. >>> >>> More over - it's a disaster waiting to be happening one day. It would be >>> unforgivable if we didn't at least help users to have a basic security in >>> place. >>> >>> The discussion is also getting too much complicated by knowledgable people >>> who point out that there's always another vulnerability or other methods to >>> bypass any security feature. IMHO that's irrelevant, should never be a >>> reason to ignore it altogether. >>> >>> We should be able to bring down this topic to a basic and sensible minimal >>> protection we provide for users. >>> >>> Can we form some kindof workgroup to investigate it further and define a >>> proposal for actions? Or a roadmap? >>> >>> And: is there a consensis to make the default startup install have >>> 'autorun' disabled, with a notifier in the top header about it? >>> >>> -Ton- >>> >>> -------------------------------------------------------- >>> Ton Roosendaal - [email protected] - www.blender.org >>> Chairman Blender Foundation - Producer Blender Institute >>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >>> >>> >>> >>> On 5 Jun, 2013, at 8:25, Campbell Barton wrote: >>> >>>> On Wed, Jun 5, 2013 at 4:21 PM, Knapp <[email protected]> wrote: >>>>> On Wed, Jun 5, 2013 at 8:03 AM, Knapp <[email protected]> wrote: >>>>>> As a normal hobby users, the biggest risk that I see is downloading a >>>>>> blend from the net and opening it. This is not something we are likely >>>>>> to give up. So, warning or not, what good is it? I need some way to >>>>>> know if the file is good or bad. I don't see an answer. I would say a >>>>>> good third of the users or more download blends for learning at least >>>>>> and often for producing their own stuff. >>>>> >>>>> What might be much more useful is a program that load a blend and tell >>>>> me what it might do. For example, does it run scripts, does it have >>>>> crazy large data sets? If it runs scripts then it should be able to >>>>> show me them. It should look at the data sizes that the blend will use >>>>> and make guesses if it is too large. Naturally it should only open the >>>>> blend as data and not as blender would. >>>>> -- >>>>> Douglas E Knapp >>>> >>>> Such a tool isn't so hard to write, see this python module which loads >>>> up blend files without using blender. >>>> http://blender-aid.googlecode.com/svn/trunk/src/blendfile.py >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
