Re: [Bf-committers] Security gets in the way
I wonder how Sketchup deals with this issue with their embedded ruby... On 4/30/10, Benjamin Tolputt btolp...@internode.on.net wrote: Campbell Barton wrote: Best bring this up next meeting and come to some consensus. I wasn't in IRC for the decision either :) Interesting to note :) However I'm going away this weekend, can make it for the next one though (May 9th). Is this a meeting that would be open to other participants? I assume that there are meetings the general public do not attend, but being on IRC - this would be something interested parties can speak at? Don't think this is urgent, can wait a week or two, would rather this be a meeting topic so we can formalize what is done, rather then some devs agreeing on IRC. This is not that urgent, no. Any immediate changes would still wait for the official Blender 2.5/2.6 release before getting into the hands of the public, and that is some time away. Any non-immediate changes (on the wild, off-chance something drastic is accepted as worth looking into) will need to wait until after said release. In any case, I doubt two weeks are going to matter much either way. Two to three years on the other hand might be asking too much ;) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Sent from my mobile device From Luke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] parsing Blender and math expressions?
On 30 apr 2010, at 12:00, bf-committers-requ...@blender.org wrote: Triggered by the crazily exploded security/sandboxing talk, I looked a bit into what kind of mathematical expression parsers etc. well, I was triggered too, and having just recently thought about pragmatic en pythonic ways to get around with sandboxing and downscaling Python without giving up its basic elegance as front-end for artistic programming, I decided to become finally a bit active in this mailing list; my basic approach is the other way around of parsing source code: making decorators that analyse generated byte-code and even transform byte-code; I have used this in an IDE for advanced impact-analysis and global flow analysis that work through metaclasses (in contrast to pychecker), and also for generating 'bytecode' for extreme small sensor nodes. at this moment I am working on a bridge between Python and Lua, it is a chunk decorator that maps Lua syntax and semantics 1-1 on natural Python syntax and semantics, it executes directly within Python, and its __str__ produces the equivalent LUA source code; and this is my pragmatic and scalable suggestion towards more security: the total amount of Python code in a Blender application in general will not be that huge ( 1 lines); Pythons standard compiler is very fast, and filters on produced byte-code can be fast too. if such filters classify compiled code in a certain scale of trust, it is up to the user (or moderator) to do some code inspection of indicated low trust without the need to look everywhere. ~Theo ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
I'm sorry Ben, I did not mean to offend. Do Nothing is always an option, and I was alerted that option 5 already covered it. While I grant you that it is a possibility that something may happen, I was trying to say this thread was like trying to design a building when you don't have a customer, don't know what magnitude earthquakes it has to withstand, what the outside temperature range is, whether it has to be airtight, what gravity is, and all those other unknowns. We could just as easily be sitting here debating the best building solution when one guy is talking about a building in California, another in Finland, and another on the Moon. One guy says we should use Concrete (Lua), another Glass (pypy), and so on. No thread yet that I have seen has identified any specific python call that should be blocked or filtered. The Do Nothing until it happens approach is the most efficient way to apply sparse and volunteer labor to long tails - events that have not happened but could but have a very low probability of happening. I think we need a real-world case or practical detailed requirements and use cases. --Roger ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Hi all, As a reminder: IRC meetings are open for everyone. We report on progress, define actions and planning, and make decisions when needed. Meetings are not meant for discussions, for that this list or any time outside meetings is better suited. Decisions are 'in consensis' by default, or at least should be supported by the active maintainers of this part of the code. A solution for this issue would be to appoint a small team to look into this issue, and come with a proposal. This team should consist of active developers/contributors/documentors, and be at least representative for the code or module maintainers. Everyone here has had a chance to reflect opinions and that's loud and clearly heard already. Next step is just accepting a roadmap how to progress, and move on. :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 30 Apr, 2010, at 8:29, Benjamin Tolputt wrote: Campbell Barton wrote: Best bring this up next meeting and come to some consensus. I wasn't in IRC for the decision either :) Interesting to note :) However I'm going away this weekend, can make it for the next one though (May 9th). Is this a meeting that would be open to other participants? I assume that there are meetings the general public do not attend, but being on IRC - this would be something interested parties can speak at? Don't think this is urgent, can wait a week or two, would rather this be a meeting topic so we can formalize what is done, rather then some devs agreeing on IRC. This is not that urgent, no. Any immediate changes would still wait for the official Blender 2.5/2.6 release before getting into the hands of the public, and that is some time away. Any non-immediate changes (on the wild, off-chance something drastic is accepted as worth looking into) will need to wait until after said release. In any case, I doubt two weeks are going to matter much either way. Two to three years on the other hand might be asking too much ;) ___ 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] Single frame netrender
Hi, Are you sure they didn't mean they wanted to be able to render a single frame on more than one machine? For tile dispatch, what's needed is a way to specify the rendered tile on command line as well as a way to load render results per tile (or at least an easy way to recomposite the full frame). Martin PS: The change you did is fine for sure, but it don't think it's usually what people think of when they talk about distributed rendering of single frames. --- On Fri, 4/30/10, Jeroen Bakker j.bak...@atmind.nl wrote: From: Jeroen Bakker j.bak...@atmind.nl Subject: [Bf-committers] Single frame netrender To: bf-blender developers bf-committers@blender.org Received: Friday, April 30, 2010, 2:52 AM Hi all, A company contacted me to make a netrenderer what supported single frame jobs. Looking in the code I found out that the fix was very easy so created a patch for it. It sends the current frame as a job to netrender. https://projects.blender.org/tracker/index.php?func=detailaid=22211group_id=9atid=127 regards, Jeroen ___ 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] Single frame netrender
+1 while no single machine of mine (I have 8) can render a single frame of BBB, or even ED, (malloc returns 0), my hope is that if I could get the tile small enough, each would be able to render a portion, and then one could stitch them together. --Roger From: Martin Poirier the...@yahoo.com To: bf-blender developers bf-committers@blender.org Sent: Fri, April 30, 2010 8:39:17 AM Subject: Re: [Bf-committers] Single frame netrender Hi, Are you sure they didn't mean they wanted to be able to render a single frame on more than one machine? For tile dispatch, what's needed is a way to specify the rendered tile on command line as well as a way to load render results per tile (or at least an easy way to recomposite the full frame). Martin PS: The change you did is fine for sure, but it don't think it's usually what people think of when they talk about distributed rendering of single frames. --- On Fri, 4/30/10, Jeroen Bakker j.bak...@atmind.nl wrote: ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Single frame netrender
Would compositing with nodes be a problem since one needs data from bordering pixels in order to do certain operations such as blur? On Fri, Apr 30, 2010 at 3:00 PM, Roger Wickes rogerwic...@yahoo.com wrote: +1 while no single machine of mine (I have 8) can render a single frame of BBB, or even ED, (malloc returns 0), my hope is that if I could get the tile small enough, each would be able to render a portion, and then one could stitch them together. --Roger From: Martin Poirier the...@yahoo.com To: bf-blender developers bf-committers@blender.org Sent: Fri, April 30, 2010 8:39:17 AM Subject: Re: [Bf-committers] Single frame netrender Hi, Are you sure they didn't mean they wanted to be able to render a single frame on more than one machine? For tile dispatch, what's needed is a way to specify the rendered tile on command line as well as a way to load render results per tile (or at least an easy way to recomposite the full frame). Martin PS: The change you did is fine for sure, but it don't think it's usually what people think of when they talk about distributed rendering of single frames. --- On Fri, 4/30/10, Jeroen Bakker j.bak...@atmind.nl wrote: ___ 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] Modal Zoom issue
Hi all, In the latest SVN build, when you zoom it no longer releases after you let go of the mouse button. I set my zoom to Control + Alt + LMB. I can zoom just fine, but when I release the mouse button the zoom stays on, turning into a rotate if I let go of the alt key. I fixed this by modifying the 3D Zoom modal to release on any mouse click, not just middle (which is the default), and now it behaves normally. This is similar to the issue where strokes in sculpting continue after releasing the mouse. If the user changes the zoom shortcut, it makes sense for that change to cascade to a release of any of the buttons required to begin the zoom operator. Is there a way to do that? I don't think a lot of users are going to understand that they have to modify the press and release just to get one perceived key map to change. Thanks, ~ Charles ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Argh, the GCC segfault bug again!
Some time ago I was struggeling with a compiler seqfault on WinXP, MinGW. Finally I found a combination of compilation switches and gcc version 4.4.1 (TDM-2 mingw32) which allowed me to compile on my laptop (no space for VC express or such) including ffmpeg. However since today: Linking library == 'libbf_rna.a' Compiling == 'gammaCorrectionTables.c' Compiling == 'imagetexture.c' Compiling == 'initrender.c' source\blender\render\intern\source\initrender.c: In function 'calc_weight': source\blender\render\intern\source\initrender.c:195: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://www.tdragon.net/recentgcc/bugs.php for instructions. scons: *** [D:\bdev\build\win32-mingw\source\blender\render\intern\source\initrender.o] Error 1 scons: building terminated because of errors. c...@manta /d/bdev/blender Thats too bad :-( Any hints for me? Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Sorry if this discussion is considered closed, but I wanted to read everything before chiming in. On Wed, Apr 28, 2010 at 9:06 AM, Benjamin Tolputt btolp...@internode.on.net wrote: However, the sand-boxing as presented in PyPy is very crude and will do nothing to fix the issues with Python in Blender. I think this is incorrect. The way PyPy is implemented presents a possible solution. Depending on the maturity of PyPy this may be ways off, so I'm just throwing this out to be considered. PyPy is a meta-circular interpreter, what that boils down to is the fact that you can implement a python interpreter in the language with a small amount of python code. But, you don't have to implement a perfect python interpreter, you can change it a little, for example, you could inspect every function before it is dispatched and make sure it is on a white list. It seems to me a possible solution is to implement a python interpreter (in PyPy) that has a white list of functions that are allowable in certain contexts within Blender. The whole idea behind a meta-circular interpreter is that you can implement the language easily in itself, and then hack your implementation to change the language itself to your needs. Also, maybe this doesn't depend on PyPy, but maybe it is possible to write a meta-circular interpreter in the standard python distribution (I'm not a python programmer, but I know how I'd do this in Scheme :). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Argh, the GCC segfault bug again!
Did you try building without openMP? It is known to produce such crash, even in Linux. I also think it is only with gcc 4.4 or 4.5 but 4.3 works ok. 2010/4/30 Carsten Wartmann c...@blenderbuch.de: Am 30.04.2010 19:01, schrieb Carsten Wartmann: Compiling == 'initrender.c' source\blender\render\intern\source\initrender.c: In function 'calc_weight': source\blender\render\intern\source\initrender.c:195: internal compiler error: Segmentation fault Strange that this file wasn't changed since some weeks?! I did compile Blender the last week several times. Please submit a full bug report, with preprocessed source if appropriate. A hint for me how I can do this? Where do I get this preprocessed code? Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ 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] Security gets in the way
hi. All: I have commented extensively about the present Blender Security Model. See: http://lists.blender.org/pipermail/bf-committers/2010-March/026604.html http://lists.blender.org/pipermail/bf-committers/2010-March/026615.html I helped Leif to write up his GSOC proposal for a Security model that is abstracted away from interpreter/ API implementation constraints, which the current discussion seems mired in. PyPy, Lua, et al are not the root of the problem, and any such implementation would be necessarily constrained. The root of the problem is well articulated in the idea of Trust. Happily there are well proven ways to represent trust algorithmically. These ways are well established and adopted by the Free Software community at large. I plead with you all to learn about GnuPG, and the Web Of Trust (see above messages, including extensive citations to which you are invited to read). Ton, and Tom, please include me in the list of contributors for the Blender Security working group. Thanks. have a day.yad jdpf On Apr 30, 2010, at 8:06 AM, Ton Roosendaal wrote: Hi all, As a reminder: IRC meetings are open for everyone. We report on progress, define actions and planning, and make decisions when needed. Meetings are not meant for discussions, for that this list or any time outside meetings is better suited. Decisions are 'in consensis' by default, or at least should be supported by the active maintainers of this part of the code. A solution for this issue would be to appoint a small team to look into this issue, and come with a proposal. This team should consist of active developers/contributors/documentors, and be at least representative for the code or module maintainers. Everyone here has had a chance to reflect opinions and that's loud and clearly heard already. Next step is just accepting a roadmap how to progress, and move on. :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 30 Apr, 2010, at 8:29, Benjamin Tolputt wrote: Campbell Barton wrote: Best bring this up next meeting and come to some consensus. I wasn't in IRC for the decision either :) Interesting to note :) However I'm going away this weekend, can make it for the next one though (May 9th). Is this a meeting that would be open to other participants? I assume that there are meetings the general public do not attend, but being on IRC - this would be something interested parties can speak at? Don't think this is urgent, can wait a week or two, would rather this be a meeting topic so we can formalize what is done, rather then some devs agreeing on IRC. This is not that urgent, no. Any immediate changes would still wait for the official Blender 2.5/2.6 release before getting into the hands of the public, and that is some time away. Any non-immediate changes (on the wild, off-chance something drastic is accepted as worth looking into) will need to wait until after said release. In any case, I doubt two weeks are going to matter much either way. Two to three years on the other hand might be asking too much ;) ___ 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] Savable Operator Defaults
+1. This would be really good. Perhaps some of the issues are just that the operators currently in 2.5 are incomplete; I don't know. I do know that changing parameters for many of them causes them to behave in unintuitive ways. I think the Fracture operator shows best one of the limitations of the current operator system-- sometimes it's better to have an operator start up and only show the parameters before the user applies it. The hack that Fracture uses to achieve this is (using that little check mark box) is neat, but I personally believe there needs to be a bit of thought put into how operators work in general: - There should be a way to fire off an operator without applying it, so that settings can be changed and that those settings stick between uses. - There should be a better system for how operator parameters are changed and applied live on objects, because whatever's going on under the hood right now (IIRC changing operator parameters calls an Undo, then reapplies the operator?) is not very stable. (Undo in 2.5, in general, crashes a lot for me.) I'm thinking the operator class should be extended so that the operators restore what they've changed instead of the undo system, while they're live, and then that data gets removed when the operator's class goes out of scope when the tool changes. I'm not sure how to approach either. In Maya you get those little boxes next to tools that have parameters you can change which bring up the properties box for the tool; there really isn't a place for those to exist in Maya. Although, perhaps defaults could be set by executing an operator in a different fashion from the space bar search. For example, perhaps hitting shift+enter after searching for an operator instead of enter just pops up the tool properties but does not activate the tool. Modo's system for this really works -- you enable the tool, and at any time you can change any parameter and see it updated in real time, but for this to work they have a system in which the operator never stops executing until the user drops the tool. I don't mean to say Blender should copy either, but it'd be nice to hear what other people think of how the workflow could be made better. ~ C On 2010-04-30, at 2:27 PM, Wahooney wrote: Has any thought been given to the saving of default values for operators? For instance, in my case: I'd like to set up default values for exporting to FBX. I know that the defaults can be changed in the .py, which is easy enough if you know how, but may be out of the scope of your standard user. I'm thinking that the defaults could be saved into .b.blend on a per operator basis, instead of all operators having all settings saved into .b.blend from the get go, which could be a difficult to impossible task. Regards, Keith ___ 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] Security gets in the way
Jason Wilkins wrote: I think this is incorrect. The way PyPy is implemented presents a possible solution. Depending on the maturity of PyPy this may be ways off, so I'm just throwing this out to be considered. PyPy is a meta-circular interpreter, what that boils down to is the fact that you can implement a python interpreter in the language with a small amount of python code. I am not against an embedded Python interpreter at all. In fact, if you look at my recent comments I'm kind of leaning that way. It is not the concept I think will not work, but the current PyPy implementation which is unworkable. The current sandbox implementation of PyPy is a crude all or nothing mechanism. Which works well for running Python where you want the same permissions throughout the application. This is not the case in Blender where plugins need access to the network file system but the scene itself does not. On the other hand, extracting a Python interpreter that only allows the calling of white-listed functions and limits the namespace to the data within the scene only (i.e. I cannot find restricted modules/data by browsing the namespace) from PyPy or another program is not a terrible idea. I believe that resistance to this idea is based around the very valid question of Who is going to maintain this subset interpreter?. What happens when PyPy makes an incompatible change or the standard Python distro moves ahead of PyPy and there is a mismatch between the syntax semantic used in scripts scene drivers? These are all valid concerns for a graphics application project without a huge pool of Python engine coders available. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Security Meeting Date/Time
Would it be possible to get clarity on when this will be discussed in IRC. Some of us are in a timezone where we need to make a special effort to be awake and logged in for it. Campbell suggested this be discussed next weekend. Given his role in Python code maintenance, I expect this delay is accepted (i.e. we are not talking about this on Sunday coming up but next week?) but am not sure about it. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
I believe that security is 10% technical and 90% social problem, so web of trust + educating users on security issues seems to be most logical solution and requires the least amount of changes in Blender's and third party plugins' code. It seems to work for Mozilla Firefox, for example, which is another OSS project that has a rich plugin infrastructure. And it's killing two birds with one stone: both security and usability. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security Meeting Date/Time
On the next dev meeting, Sunday May 2nd (1400 UTC). Martin --- On Fri, 4/30/10, Benjamin Tolputt btolp...@internode.on.net wrote: From: Benjamin Tolputt btolp...@internode.on.net Subject: [Bf-committers] Security Meeting Date/Time To: bf-blender developers bf-committers@blender.org Received: Friday, April 30, 2010, 9:29 PM Would it be possible to get clarity on when this will be discussed in IRC. Some of us are in a timezone where we need to make a special effort to be awake and logged in for it. Campbell suggested this be discussed next weekend. Given his role in Python code maintenance, I expect this delay is accepted (i.e. we are not talking about this on Sunday coming up but next week?) but am not sure about it. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
On Fri, Apr 30, 2010 at 7:39 PM, Benjamin Tolputt btolp...@internode.on.net wrote: I believe that resistance to this idea is based around the very valid question of Who is going to maintain this subset interpreter?. I understand this and is why I need to look and see just how simple it is to write a python interpreter in pypy. If pypy really is a meta-circular interpreter it should be a small amount of code to maintain. For example, a Scheme interpreter, written in Scheme is tiny. Most people probably think of how difficult it is to write a python interpreter in C and think it would be a ton of code but it could actually be very simple if written in PyPy. I won't say much more until I actually find the time to look at it though. On Fri, Apr 30, 2010 at 9:05 PM, Ruslan Merkulov r.merku...@gmail.com wrote: I believe that security is 10% technical and 90% social problem, so web of trust + educating users on security issues seems to be most logical solution I totally agree with this. However, the 10% still needs to be done and I think that part of that 10% is at least declaring that rigs should not be able read files and connect to the internet unless the user really wants them to. That's my 2 cents :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Jason, there is already a sandbox version of pypy. http://codespeak.net/pypy/dist/pypy/doc/sandbox.html As regards web of trust and GPG, there is python GnuPG http://code.google.com/p/python-gnupg/ LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
