Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
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. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
On Wed, Jun 5, 2013 at 8:03 AM, Knapp magick.c...@gmail.com 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 Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
On Wed, Jun 5, 2013 at 4:21 PM, Knapp magick.c...@gmail.com wrote: On Wed, Jun 5, 2013 at 8:03 AM, Knapp magick.c...@gmail.com 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 Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, have you tried to build a RelWithDebInfo Build of OpenEXR? This could help to track down the Error if the Debug Lib doesn't help. /Jürgen Am 05. Juni 2013 um 10:40 schrieb Dalai Felinto dfeli...@gmail.com: I found where the crash is (still no idea why it's crashing): # openexr_api.cpp::imb_load_openexr (...) (...) Mem_IStream *membuf = new Mem_IStream(mem, size); # To get there I had to build a debug build and replace the linking to: \lib\windows\openexr\lib\IlmImf.lib instead of: \lib\windows\openexr\lib\IlmImf_d.lib And it consistently breaks on Release for windows and 64, but not for Debug. Any clues on how to debug this? -- Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/3 Jürgen Herrmann shadow...@me.com: Hi Dalai, I can recompile the libs tomorrow. I'll contact you when I am done. I doubt that this will change anything though. The header that was missing wasn't installed by the CMake build routine it was not missing at compile time. It was just omitted by the install script. But nevertheless I'll try to recompile them for you. Otherwise we should try to report a bug to the OpenEXR devs. It could be an error in the libs. /Jürgen Am 03.06.2013 um 20:58 schrieb Dalai Felinto dfeli...@gmail.com: Hi again, The new OIIO libraries don't make any difference. OIIO depends on OpenEXR and not the other way around. So although that could I can't see how they would change things. I remember when you first uploaded the libraries you forgot a header file (which I'm using in the code). I wonder if it's related and the first release build is buggy. The ideal would be to rebuild OpenEXR for release and hope it fixes the problem. If you don't want to commit the libs without knowing they will fix the problem you can put them on blender.org ftp incoming folder. (or poke me on IRC and we can find a solution). (or checkout the svn code for multiview, it should be easy to reproduce the problem in your windows station) Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/2 Jürgen Herrmann shadow...@me.com: Hi Dalai, Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. Please try to do a SVN update on your libs and compile again using these. These problems are strange... I will have a closer look on this tomorrow. /Jürgen Am 02.06.2013 um 20:16 schrieb Dalai Felinto dfeli...@gmail.com: Hi Jurgen, I think the problem is the release library. Even with cmake+msvc the exr sample image fails when I build release. And I just tested with the 1.2 oiio libraries and I still get the same error with scons+msvc debug. Remember that you forgot to include a header in your first commit of the library? I wonder if that was somehow also missing when you built it. I don't know. -- Dalai ___ 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 ___ 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
[Bf-committers] CUDA performance analysis (with my experimental changes)
I modified the the CUDA renderer to take environment variable overrides to allow a performance test to iterate through several combinations of parameters. The code has many performance optimizations that I have made to eliminate redundant memory allocations, using all asynchronous operations (all memory copies and kernel launches), using two streams fed from a single thread (interleaved 1:1 between them) each processing a separate tile, and using a RenderBuffers pool to eliminate those allocations and frees. Surprisingly, the largest register count with the smallest warp size had the best time! Best time has 33% occupancy. Tested on SM 2.0 hardware (single GTX 580) rendered from command line. Display driver is nvidia-experimental-310. Scene is the BMW scene with the default size (1280x600), percent at 75% (result is 960x450), tile size at the default 64x64. Using CUDA 5.0 toolkit on Linux Mint 14 Mate 64-bit.Linux kernel is 3.5.0-28-generic. CPU is 6-core Core I7 990x Extreme Edition 12MB L3. PCIe 16x bus. 20GB 1066 RAM in triple channel configuration. Bus interface is 16x PCIe. *registers* *warp size* *optimization* *time (s) * 63 64 3 70.80 63 64 2 70.81 63 64 1 70.87 63 64 0 70.96 63 64 4 71.03 42 64 3 72.10 42 64 0 72.17 42 64 4 72.21 32 64 0 72.44 42 64 2 72.47 32 64 4 72.49 63 256 4 72.61 63 256 3 72.65 63 256 1 72.70 32 64 2 72.77 42 64 1 72.78 32 64 1 72.82 63 256 2 73.09 63 256 0 73.27 32 64 3 73.55 42 256 3 74.16 42 256 0 74.26 42 256 2 74.34 42 256 4 74.39 42 256 1 74.42 32 256 2 74.57 32 256 4 74.57 32 256 0 74.60 24 64 3 74.62 32 256 3 74.70 24 64 1 74.75 24 64 2 75.09 32 256 1 75.15 24 64 4 75.30 24 64 0 75.39 24 256 3 76.90 20 64 1 76.92 20 64 2 77.12 20 64 0 77.14 20 64 3 77.14 24 256 1 77.42 24 256 2 77.64 20 64 4 77.65 24 256 0 78.31 20 256 1 79.21 20 256 4 79.23 20 256 2 79.43 *20**256* *3* *79.75* 24 256 4 79.81 20 256 0 79.83 32 10242 100.93 32 10243 100.95 32 10240 101.25 32 10244 101.28 32 10241 101.47 24 10242 105.52 24 10240 105.62 24 10244 106.00 24 10243 106.39 24 10241 106.53 20 10241 111.51 20 10242 111.61 20 10243 111.69 20 10240 111.74 20 10244 111.84 The following combinations fail due to insufficient resources: /42//1024/ /2/ /failed/ /63//1024/ /4/ /failed/ /42//1024/ /4/ /failed/ /63//1024/ /1/ /failed/ /63//1024/ /2/ /failed/ /42//1024/ /0/ /failed/ /42//1024/ /1/ /failed/ /63//1024/ /0/ /failed/ /42//1024/ /3/ /failed/ /63//1024/ /3/ /failed/ I am going to re-run the analysis with even smaller warp sizes to see what happens. -Doug ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
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 - t...@blender.org - 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 magick.c...@gmail.com wrote: On Wed, Jun 5, 2013 at 8:03 AM, Knapp magick.c...@gmail.com 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 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
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
Hi, Here's just some ideas to investigate: 1) Better location for temp saves - remove /tmp/ usage from our default, and move it to sane a path inside user space. We can call this sandbox or so, which (on first use) could also be confirmed by users to be used as such. - sandbox paths could simply be the ones without / or // or C:\\ etc. 2) Communicate to users all saving C/C++ code well - Each save of a file should be printed in terminals. - Only allow non-user approved saves to files in sandbox (like temp files). - All other saves by tools should go by design via user confirmations (popup save-over). For tools with standard output paths (bakes, caches, anim render) only relative paths should be allowed (without confirmation). 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. 4) Replace Python's os module - For standard releases, the os module could follow same file save rules as our C code does. Untrusted files could default be allowed to use sandbox only. -Ton- Ton Roosendaal - t...@blender.org - 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 - t...@blender.org - 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 magick.c...@gmail.com wrote: On Wed, Jun 5, 2013 at 8:03 AM, Knapp magick.c...@gmail.com 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 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
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 - t...@blender.org - 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 - t...@blender.org - 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 magick.c...@gmail.com wrote: On Wed, Jun 5, 2013 at 8:03 AM, Knapp magick.c...@gmail.com 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
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
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 - t...@blender.org - 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 - t...@blender.org - 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 - t...@blender.org - 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 magick.c...@gmail.com wrote: On Wed, Jun 5, 2013 at 8:03 AM, Knapp magick.c...@gmail.com 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
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
In reply to Ton Roosendaal (t...@blender.org): From: Ton Roosendaal t...@blender.org Date: Wed, 5 Jun 2013 14:35:16 +0200 To: bf-blender developers bf-committers@blender.org X-Mailer: Apple Mail (2.1283) Subject: Re: [Bf-committers] Please turn off Auto Run Python Scripts by default Reply-To: bf-blender developers bf-committers@blender.org Hi, 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. And we could create a file that stores oked identifiers. Similar to ssh's known_hosts If you open a file with an unknown identifier ask do you really want to open the file, and do you want to store that identifier as trusted. Kent ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
Ton Roosendaal t...@blender.org wrote: 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- This is likely to be problematic. I know I've relied on the os module for a number of my own internal scripts for pipeline as well as other tasks... and not just for file I/O. For example, the subprocess library is likely a huge security hole, but it's incredibly useful (almost required) for calling programs that don't have a Python API (or only a python2 API). Sure, a lot of these things could be done outside of Blender, but it's far more convenient to have it inside... especially for external artists who don't roll their own Blender. In addition to my own esoteric scripts, I'd be curious about how this might impact Import/Export scripts as well as external renderers. -Jason ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
Disabling os module might cause a lot of problems. Pipeline and other batch scripts rely on it a lot. We also use a lot of absolute path in our pipeline scripts since we move a lot of files across directories for version control , publishing to the next stage , import directories of the stages , etc ., etc . using relative paths causes a lot of problems here . A cli option to disable all this security thingies would be great boon if at all the security measures are implemented. On Wed, Jun 5, 2013 at 8:46 PM, Jason van Gumster ja...@handturkeystudios.com wrote: Ton Roosendaal t...@blender.org wrote: 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- This is likely to be problematic. I know I've relied on the os module for a number of my own internal scripts for pipeline as well as other tasks... and not just for file I/O. For example, the subprocess library is likely a huge security hole, but it's incredibly useful (almost required) for calling programs that don't have a Python API (or only a python2 API). Sure, a lot of these things could be done outside of Blender, but it's far more convenient to have it inside... especially for external artists who don't roll their own Blender. In addition to my own esoteric scripts, I'd be curious about how this might impact Import/Export scripts as well as external renderers. -Jason ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- regards - shrinidhi Even god fails to understand a human until his death! http://www.linkedin.com/in/shrinidhi666 https://github.com/shrinidhi666 http://www.imdb.com/name/nm3025616 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
Hi, I am not proposing to make advanced system adminstration entirely impossible. It's just not a sane default to release, nor to give to everyone in a studio. The challenge is to find out a good, sane and usable way to configure Blender securely. It could work all fine for people in studios on daily work, and for occasional users who play with Blender and download files. And it could work for the TD to do massive data manipulations. Needless to say: if you run a movie making bizz, you also will set up accounts and permissions in a way you protect valuable data. A user accidentally deleting every shot is not fun ever. -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 5 Jun, 2013, at 17:29, Shrinidhi Rao wrote: Disabling os module might cause a lot of problems. Pipeline and other batch scripts rely on it a lot. We also use a lot of absolute path in our pipeline scripts since we move a lot of files across directories for version control , publishing to the next stage , import directories of the stages , etc ., etc . using relative paths causes a lot of problems here . A cli option to disable all this security thingies would be great boon if at all the security measures are implemented. On Wed, Jun 5, 2013 at 8:46 PM, Jason van Gumster ja...@handturkeystudios.com wrote: Ton Roosendaal t...@blender.org wrote: 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- This is likely to be problematic. I know I've relied on the os module for a number of my own internal scripts for pipeline as well as other tasks... and not just for file I/O. For example, the subprocess library is likely a huge security hole, but it's incredibly useful (almost required) for calling programs that don't have a Python API (or only a python2 API). Sure, a lot of these things could be done outside of Blender, but it's far more convenient to have it inside... especially for external artists who don't roll their own Blender. In addition to my own esoteric scripts, I'd be curious about how this might impact Import/Export scripts as well as external renderers. -Jason ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- regards - shrinidhi Even god fails to understand a human until his death! http://www.linkedin.com/in/shrinidhi666 https://github.com/shrinidhi666 http://www.imdb.com/name/nm3025616 ___ 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
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
Hacked os module isn't really an option, Python uses this for its internal operations all over the place - a lot of python modules are written in Python so these would break. In python3.3 module dir... find -name *.py | xargs grep \bos\. | wc -l -- 7833 Attempting to let Python do its own thing but sandbox Blender scripts also cant work well, In the BGE we did have some basic security (disable some modules open()... iirc), But this is trivially easy to workaround - as in one line of python to get access to the real modules/functions. The only way I could see this working would be to do this on a libc level - replacing pythons own calls to open() / fopen() etc. But this also gives high risk of breaking Python its self. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
Another +1 for not changing the OS module, or anything else for that matter. I use lots of python system-related modules, including OS, in my import/export/interop pipeline. If it is broken I will most likely not be using blender anymore (seriously). Additionally, I don't believe security in blend files is an issue anyway. If you have accepted a file from an untrusted source and opened it, YOU are the security risk, not the program you opened it with. AVIs, DOCs, and various other data files have had and still do have security risks associated with them (whether internal scripts are allowed to run or not). This problem is certainly not unique to blend files, and certainly not due solely to the fact that blender allows python scripts to run. This is a non-issue. The Trusted Source checkbox is a nice feature, I guess, but realistically I've never used it because I want all blends to open and work as intended by the creator. If I think it might be a malicious file, I don't accept it in the first place. That's where security starts, and ultimately ends. On Wed, Jun 5, 2013 at 10:55 AM, Campbell Barton ideasma...@gmail.comwrote: Hacked os module isn't really an option, Python uses this for its internal operations all over the place - a lot of python modules are written in Python so these would break. In python3.3 module dir... find -name *.py | xargs grep \bos\. | wc -l -- 7833 Attempting to let Python do its own thing but sandbox Blender scripts also cant work well, In the BGE we did have some basic security (disable some modules open()... iirc), But this is trivially easy to workaround - as in one line of python to get access to the real modules/functions. The only way I could see this working would be to do this on a libc level - replacing pythons own calls to open() / fopen() etc. But this also gives high risk of breaking Python its self. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- -- Jace Priester Threespace Imaging jacepries...@threespaceimaging.com 559-284-0904 -- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles benchmark as promised.
Yay, I am done. http://download.shadowrom.de/Benchmark.pdf While doing this benchmark I tried to replace the math library used with the AMD libm implementation. This was actually slower on all systems (even the amd system) so I left these results out. The more I read about MSVC the more I have the feeling that the compiler doesnt optimize math functions properly. GCC seems to be way better on that. /Jürgen -Ursprüngliche Nachricht- Von: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] Im Auftrag von Jürgen Herrmann Gesendet: Dienstag, 4. Juni 2013 21:29 An: bf-committers@blender.org Betreff: [Bf-committers] Cycles benchmark as promised. Alright I said I will do a benchmark, so here it is (partial) I am not done yet but wanted to share the first draft with you guys before I go to sleep. Ill add in another test system tomorrow and refine the visualization. You can download the pdf file here: http://download.shadowrom.de/Benchmark.pdf This is really getting interesting *g* /Jürgen ___ 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
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
On Thu, Jun 6, 2013 at 5:21 AM, Jace Priester jacepries...@threespaceimaging.com wrote: Another +1 for not changing the OS module, or anything else for that matter. I use lots of python system-related modules, including OS, in my import/export/interop pipeline. If it is broken I will most likely not be using blender anymore (seriously). Additionally, I don't believe security in blend files is an issue anyway. If you have accepted a file from an untrusted source and opened it, YOU are the security risk, not the program you opened it with. AVIs, DOCs, and various other data files have had and still do have security risks associated with them (whether internal scripts are allowed to run or not). This problem is certainly not unique to blend files, and certainly not due solely to the fact that blender allows python scripts to run. This is a non-issue. The Trusted Source checkbox is a nice feature, I guess, but realistically I've never used it because I want all blends to open and work as intended by the creator. If I think it might be a malicious file, I don't accept it in the first place. That's where security starts, and ultimately ends. Developer working on the bug tracker you have to open many blend files created by random users, so the assurance those blend files wont run arbitrary python code is something I'm glad to have. Changing trusted defaults, communicating to user more clearly what they do, adding option in header to reload-trusted, area all fine. But I'd stop short of actually making decisions for users, eg, not letting a script write to some location they would normally be allowed to or limiting python functionality to the point useful operations are disabled. If we start turning off useful features it makes it a challenge for script authors to workaround and knowing how CPython is designed they will surely be able to do it without much effort. Then we just loose a lot of dev time trying to secure something that is inherently insecure. Trying to sandbox python is more of a research project - perhaps we can setup a state where pythons internals are temporarily disabled to the point files cant be modified, or pre-process python bytecode and disallow certain features, but I see this as a time sink - at that point we probably should be asking ourselves why we use Python at all, and not something like Lua or check on pypy which can be sand-boxed apparently. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles benchmark as promised.
hi from these results it seems the fastest in cpu and gpu is mingw (with one exception for msvc). i think as a freelance 30-40% of render time reduction is a big advantage, has anyone tested the mingw openmp fix? Regards Yousef Harfoush ba...@msn.com From: shadow...@me.com To: bf-committers@blender.org Date: Wed, 5 Jun 2013 21:57:11 +0200 Subject: Re: [Bf-committers] Cycles benchmark as promised. Yay, I am done. http://download.shadowrom.de/Benchmark.pdf While doing this benchmark I tried to replace the math library used with the AMD libm implementation. This was actually slower on all systems (even the amd system) so I left these results out. The more I read about MSVC the more I have the feeling that the compiler doesn’t optimize math functions properly. GCC seems to be way better on that. /Jürgen -Ursprüngliche Nachricht- Von: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] Im Auftrag von Jürgen Herrmann Gesendet: Dienstag, 4. Juni 2013 21:29 An: bf-committers@blender.org Betreff: [Bf-committers] Cycles benchmark as promised. Alright… I said I will do a benchmark, so here it is (partial) I am not done yet but wanted to share the first draft with you guys before I go to sleep. I’ll add in another test system tomorrow and refine the visualization. You can download the pdf file here: http://download.shadowrom.de/Benchmark.pdf This is really getting interesting *g* /Jürgen ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
have you tried to build a RelWithDebInfo Build of OpenEXR? I tried, but if I build Blender as debug using the openexr build as Release with Debug Info it crashes at launch: http://www.pasteall.org/42864 I've been debugging via a computer I have access via RDC so it's really annoying btw. Leaving this RelWithDebInfo aside and focusing on the original problem (library working in debug but not in release), does any one have a clue on what can cause that? Namespace conflict? ...? ...? -- Dalai 2013/6/5 Jürgen Herrmann shadow...@me.com: Hi Dalai, have you tried to build a RelWithDebInfo Build of OpenEXR? This could help to track down the Error if the Debug Lib doesn't help. /Jürgen Am 05. Juni 2013 um 10:40 schrieb Dalai Felinto dfeli...@gmail.com: I found where the crash is (still no idea why it's crashing): # openexr_api.cpp::imb_load_openexr (...) (...) Mem_IStream *membuf = new Mem_IStream(mem, size); # To get there I had to build a debug build and replace the linking to: \lib\windows\openexr\lib\IlmImf.lib instead of: \lib\windows\openexr\lib\IlmImf_d.lib And it consistently breaks on Release for windows and 64, but not for Debug. Any clues on how to debug this? -- Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/3 Jürgen Herrmann shadow...@me.com: Hi Dalai, I can recompile the libs tomorrow. I'll contact you when I am done. I doubt that this will change anything though. The header that was missing wasn't installed by the CMake build routine it was not missing at compile time. It was just omitted by the install script. But nevertheless I'll try to recompile them for you. Otherwise we should try to report a bug to the OpenEXR devs. It could be an error in the libs. /Jürgen Am 03.06.2013 um 20:58 schrieb Dalai Felinto dfeli...@gmail.com: Hi again, The new OIIO libraries don't make any difference. OIIO depends on OpenEXR and not the other way around. So although that could I can't see how they would change things. I remember when you first uploaded the libraries you forgot a header file (which I'm using in the code). I wonder if it's related and the first release build is buggy. The ideal would be to rebuild OpenEXR for release and hope it fixes the problem. If you don't want to commit the libs without knowing they will fix the problem you can put them on blender.org ftp incoming folder. (or poke me on IRC and we can find a solution). (or checkout the svn code for multiview, it should be easy to reproduce the problem in your windows station) Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/2 Jürgen Herrmann shadow...@me.com: Hi Dalai, Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. Please try to do a SVN update on your libs and compile again using these. These problems are strange... I will have a closer look on this tomorrow. /Jürgen Am 02.06.2013 um 20:16 schrieb Dalai Felinto dfeli...@gmail.com: Hi Jurgen, I think the problem is the release library. Even with cmake+msvc the exr sample image fails when I build release. And I just tested with the 1.2 oiio libraries and I still get the same error with scons+msvc debug. Remember that you forgot to include a header in your first commit of the library? I wonder if that was somehow also missing when you built it. I don't know. -- Dalai ___ 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 ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] I have a build error r57168.
By the way, what's wrong with the buildbots for Windows builds? I wanted to download a recent build for comparison but it seems that they are offline? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
