Re: [Bf-committers] Blender developer weekly meeting minutes - June 9, 2013

2013-06-10 Thread Ton Roosendaal
Hi, It is mostly UI/rna code that makes it too much work, not cycles itself (which is easy). -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018

Re: [Bf-committers] Python security - proposal

2013-06-10 Thread Ton Roosendaal
Hi Daniel, I fully agree that such popups are quite meaningless, and will result in annoying users (because either the blend doesnt work, or they risk getting their hd wiped ;) That's why it needs to be combined with point three: >> 3) Implement a friendly (easy to use) way for marking/definin

[Bf-committers] Please keep OSL script compatibility

2013-06-10 Thread IRIE Shinsuke
Hi Cycles devs, With Blender 2.66/2.67, I've already used OSL closure specular_toon() in several .blend files (e.g. http://www.blendswap.com/blends/view/67827), but your recent commit renamed this and broke file compatibility so I have to modify many many material node settings in the older .blend

Re: [Bf-committers] Please keep OSL script compatibility

2013-06-10 Thread Thomas Dinges
Hi, changing the closure name was a step to keep the code consistent. The toon closures were only experimental before, so I rather not add file compatibility code for this change. (Not sure this is possible even, maybe with some code duplication). Thomas Am 10.06.2013 13:15, schrieb IRIE Shinsu

Re: [Bf-committers] Please keep OSL script compatibility

2013-06-10 Thread Brecht Van Lommel
I think we should preserve compatibility. It's just a matter of adding a function to stdosl.h like this closure color specular_toon(normal N, float size, float smooth) { return glossy_toon(N, size, smooth); } On Mon, Jun 10, 2013 at 1:21 PM, Thomas Dinges wrote: > Hi, > changing the closure nam

Re: [Bf-committers] Please keep OSL script compatibility

2013-06-10 Thread Thomas Dinges
Too simple, will add that. Thanks! Am 10.06.2013 14:08, schrieb Brecht Van Lommel: > I think we should preserve compatibility. It's just a matter of adding > a function to stdosl.h like this > > closure color specular_toon(normal N, float size, float smooth) { > return glossy_toon(N, size, smoot

Re: [Bf-committers] Transformation Constraint now allows applies rotation

2013-06-10 Thread Juan Pablo Bouza
Hi Aligorith! I tested the transformation constraint change with my rig and I didn't find any problem with it. (it was just a quick test) If you still think this could lead into some kind of trouble, it could be a good idea to add the offset option separately as the copy rotation constraint ha

Re: [Bf-committers] Please keep OSL script compatibility

2013-06-10 Thread IRIE Shinsuke
Hi, Thanks for the fix, but I still get errors like below: ERROR: Closure 'specular_toon' is not supported by the current renderer, called from (/tmp/tmpsxc72o.osl:15) Re-compilation solves this but resets all parameters of the OSL script nodes, so I have to set them again... Could you fix thi

Re: [Bf-committers] Python security - proposal

2013-06-10 Thread Sergey Sharybin
Couple of things, - All this stuff around "autorun scripts" is not sufficient. There're lots of other ways to inject malicious code -- for example, using eval("import os; os.system('rm -rf /')") as a driver for default cube rotation. Also, for my knowledge freestyle uses scripts for linestyles, wh

Re: [Bf-committers] Python security - proposal

2013-06-10 Thread Jürgen Herrmann
Hmm... First of all we should assume that Linux user won't usually run blender as root or in a sudo environment. So a "rm / -rf" attack shouldn't work by default. I think Windows is the real problem here, nearly every windows user (at least at home) has Admin privileges. I don't know how OSX ha

Re: [Bf-committers] Python security - proposal

2013-06-10 Thread Sergey Sharybin
Yes, sandboxing shouldn't be in the list "to be started with" for sure :) But oops, i've read original message not careful enough, pardon. Current proposal actually proposes Campbell to investigate possible ways of making blender safe. So yeah, security stuff is still goes deep enough, but i'd wai

Re: [Bf-committers] Python security - proposal

2013-06-10 Thread Jürgen Herrmann
You are right ;) I bet Campbell will come up with a decent proposal. Am 10.06.2013 um 21:47 schrieb Sergey Sharybin : > Yes, sandboxing shouldn't be in the list "to be started with" for sure :) > > But oops, i've read original message not careful enough, pardon. Current > proposal actually propo

Re: [Bf-committers] Please keep OSL script compatibility

2013-06-10 Thread Brecht Van Lommel
New fix in svn for specular_toon, it should indeed also preserve compatibility for compiled bytecode. Also the script update and preservation of node parameters should be fixed now. On Mon, Jun 10, 2013 at 6:42 PM, IRIE Shinsuke wrote: > Hi, > > Thanks for the fix, but I still get errors like bel

Re: [Bf-committers] Python security - proposal

2013-06-10 Thread Chad Fraleigh
On Mon, Jun 10, 2013 at 11:05 AM, Jürgen Herrmann wrote: > Hmm... > > First of all we should assume that Linux user won't usually run blender as > root or in a sudo environment. So a "rm / -rf" attack shouldn't work by > default. > Not from a full OS attack perspective, but it should would wipe

Re: [Bf-committers] Please turn off Auto Run Python Scripts by default

2013-06-10 Thread Campbell Barton
Update on whats going on: - Default has been changed not to auto-run scripts, with option to reload a blend if it attempts to run a script. looks like this: http://www.graphicall.org/ftp/ideasman42/trust_header.png - Since this is a user preference, Users with current preferences saved won't noti