Re: [Bf-committers] Security gets in the way
Hi all, Maybe somebody's mentioned this, but one compromise could be to add an option at installation time to select for Heightened security (some functionality disabled). This could be recommended for first-time users but not set as the default. T ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
*Mono*: On the suggestion of Mono, this is a no-go before it even get's to the starting block. The components needed to make Mono run are quite large in size and not guaranteed to be on every machine. Currently Blender runs just fine by distributing the required Python dependencies along with it (though it locates existing installations just fine as well). Doing the same for Mono would blow out the download size of the default Python by a large factor. i don't think that's true. the unity webplayer comes with mono and mono doesn't take more than 4mb there (and this includes the languages boo and unityscript). python 3.1 takes 2.7mb. i have also read on miguel de icaza's blog that mono's moonlight profile is even smaller and contains all of the important stuff. he recommended it to the unity developers. *PyPy as a solution:* The problem with PyPy is that, like the current situation, it is an all or nothing approach. PyPy will give you the choice of allowing Blender to access your file system (a requirement for import/export scripts) or will lock it down. Recall that the problem with Python isn't that it can allow access to the hard-drive, but that either EVERY Python script expression can do it or none of them can. Rigs don't need access to the network, file systems, operating system features etc; but if we give it to the import/export scripts - we give it to the rigs. Python's all or nothing problem is based on the language design modules developed around it, not the virtual machine used to execute the code (which is all PyPy is attempting to change). couldn't you run 2 separate pythons? but that would be the worst case. i really would contact the pypy developers first and get their opinion about it. i follow their mailing list a bit and there seem to be a lot of experiments going on with their sandbox. probably i am wrong but to me it seemed like some people tryed to enable/disable certain features just like it would be needed for blender. ___ 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 Thu, 4/29/10, Charles Wardlaw cward...@marchentertainment.com wrote: So you're telling me I can't modify sys.path to remove the standard Python libraries? File access is part of builtins, you can remove that. Even if you try, there's a million of sneaky ways to get it back, like the following: [t for t in type(1).__class__.__base__.__subclasses__() if hasattr(t, write)][0](/path/to/file, w).write(my payload) I'm not talking about a safe and secure sandboxed VM-- I mean literally remove the functionality. It's just a zip file or a folder or whatever, and there's no reason you can't block access to os and sys by not letting the interpreter see them. os and sys are not required for file access. Moreover, depending on the platform, they can be built into the interpreter (not external modules). The other option is code introspection-- It's simple enough to read through text and see what's imported before it's even fed to the interpreter. There's no reason that autoloaded scripts couldn't be inspected at file open for dangerous items. Good luck with that. Even with an import hook, it's possible to go around such a measure. I say leave up a message on the download page or put it in the installer that Python is not secure and that by running Blender people may be opening themselves up to attack, or pop up a message if being run interactively. Not that I've ever heard of such attacks on users of embedded Python. Sometimes it's not malicious. It could just be a poorly written script that craps files all over your HD if not run in a certain way. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture assignment workflow is confusing
+1 to mapping options being in material/modifier/whatever +1 to get shading influence settings out of texture panel and back into material (mockup presented by Doug Olivier) I believe the presence of a stack of slots in 2.4 or a list of textures in 2.5 in the Texture panels is confusing. I know it is there to allow fast browsing of textures which is great, but maybe it would be better to split it into: a. texture browser: showing names + small previews b. texture editor: showing a big (BIG) preview of the texture, and its parameters/options Just an idea Regards malefico. Roger Wickes wrote: having two texture channels mapping the SAME texture is a common thing I do with the cloud texture. One big, the other small, to give non-uniform shading. The Mat-Tex is a JOIN in database parlance. the Join table is really a separate entity. I +1 Carsten to have the mapping panels in whatever maps the texture - the world, the material, the lamp, the modifier (displacement), the whatever (video speed control? Volume Density?), since there will be variations on how it applies that particular texture to that particular object type. --Roger From: Carsten Wartmann c...@blenderbuch.de To: bf-blender developers bf-committers@blender.org Sent: Wed, April 28, 2010 10:53:12 AM Subject: Re: [Bf-committers] Texture assignment workflow is confusing Knapp schrieb: The worst bit about 2.4 was that map to and map input should have been in the textures panel not the materials panel. Or everything under the Having two materials using ONE texture but with different mapping is not that seldom and I think then it is much more logical to have the mapping in the material panel like 2.4x had. Carsten ___ 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] Security gets in the way
Charles Wardlaw wrote: So you're telling me I can't modify sys.path to remove the standard Python libraries? I'm not talking about a safe and secure sandboxed VM-- I mean literally remove the functionality. It's just a zip file or a folder or whatever, and there's no reason you can't block access to os and sys by not letting the interpreter see them. I can hear the argument about importers and exporters not working, but you could follow Tony's suggestion about popping up a message that says This can't be used because of security features and then allow the user to make a choice about what they want to do. Actually, you answer your own question. You cannot remove the os sys modules without it affecting other parts of Python. Not only the importser/exporters but other modules built into Python also refer to these module and they would crash. Removing these modules would require testing all other modules for correct behaviour. And it is not just these modules that would be useful to a malware author. there is subprocess, socket, threading, email, io, platform, shutil, and many more that could be used to get access to resources that are not required for rigging/animation purposes in Blender. And this is ignoring the built-in functions that don't require the loading of modules... like the open() function which allows the creation of /or reading of files so long as you know a valid path. Once you've gone to all that effort of hacking Python to be... well, not Python - why stick with the language? I think the biggest problem is that everyone is looking for an easy answer and there simply isn't one. There are ways around any security system. The arguments for this kind of stuff seem to be about protecting the retired grandfathers and soccer moms. This I can agree with you on, the user-base we're looking to help are the soccer moms, retired grandfathers, legal secretaries, and tree loppers... Those kind of first-time users don't need OBJ import. ...and then you lose me entirely. Sorry, but until such time as .blend is a standard file format, how exactly do you expect people to fill a basic scene? If it's open content, it is almost invariably available in an OBJ format. Collada is picking up speed, but it is not there yet. Hell, The web-comic artist-to-be I talked about in an earlier email gets a majority of her art from Poser props exported as, you guessed it, OBJ files. Or if people really care about security, move importers and exporters and geometry shaders that write PTC files and anything else requiring disk access into C code to get around that limitation. os and sys are nice to have for certain kinds of directory walking, but they're not necessary for the majority of Blender's functionality. This is indeed a possibility, but given that the general environment here seems adverse to anything resembling a large amount of effort to securing Blender (a viable understandable position); I think this is another non-starter solution. Especially when there is no greasy wheel needing a kick. We're already facing outright hostility to the effort required for a basic on/off solution to the problem from core developers. I don't think it is a long bow to draw expecting the moving all standard import/export plugins to C idea to be tossed aside almost immediately. The other option is code introspection-- It's simple enough to read through text and see what's imported before it's even fed to the interpreter. There's no reason that autoloaded scripts couldn't be inspected at file open for dangerous items. OK, have you actually read Campbell's emails to the list on this? It is *trivial* to hide the real intent of Python code, /especially/ from automated code introspection functionality. Virii make it through the filters designed by multi-million dollar companies *dedicated* to this task. It took Campbell not even a day after reading how two research papers suggested securing Python to find away around it; even if it takes your average malware author four times the amount of time to get around our open-source filter - he'll have it done in under a week tops. I don't think any of the arguments for this security hold water. Sure, there will eventually be .blend viruses, and they'll be scanned for by programs like Avast and filtered out of mail messages and a few users are going to get bitten, badly. But the one thing nobody is saying is that since Blender's open source, it doesn't matter whether or not the user downloads a bad .blend. Users who are likely to get hurt by such problems are just as likely to download a special custom build with extra functionality! which has even worse stuff bundled inside. There's already a community notion that if you want to try out the latest and greatest, you go to graphicall. Who makes those builds? How do I know people aren't hacking the C code to steal my password? And if those builds are
Re: [Bf-committers] Security gets in the way
File access is part of builtins, you can remove that. Even if you try, there's a million of sneaky ways to get it back, like the following: [t for t in type(1).__class__.__base__.__subclasses__() if hasattr(t, write)][0](/path/to/file, w).write(my payload) There're ways around any security measure; even UBISoft's uncrackable DRM for their games was cracked this weekend. os and sys are not required for file access. Bad example, but I hope the point was still made. Moreover, depending on the platform, they can be built into the interpreter (not external modules). Aren't all 2.5 versions using an internal Python3.1 distribution that BF controls? If folks are serious about this, external python in official builds can be disallowed and the internal Python stack can be nerfed. Good luck with that. Even with an import hook, it's possible to go around such a measure. Sure, but again, people could get around most of the suggestions that have come up in this thread. Trying to catch the broadest attempts at security breaches is all anyone can really be tasked with. At some point someone is going to find a way around the security, and there will be issues. It's unavoidable. Sometimes it's not malicious. It could just be a poorly written script that craps files all over your HD if not run in a certain way. Which is a very good point, and adds validity to the notion of a central trusted scripts repository. Having a trusted scripts / rigs place online that new users are pointed towards (instead of long BlenderArtists threads) would go much further to solving these issues than adding security layers to the software and inconveniencing long-time power users IMO. Then again, it needs someone to manage it. ~ C ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Is time to end up this security discussion: paperware is very beautiful but never leave the planification phase. The pro-security team could work on a prototype that could shut up the rest of us that think this discussion is getting in the way, meanwhile, the rest of us could continue improving blender. regards farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
And it is not just these modules that would be useful to a malware author. there is subprocess, socket, threading, email, io, platform, shutil, and many more that could be used to get access to resources that are not required for rigging/animation purposes in Blender. And this is ignoring the built-in functions that don't require the loading of modules... like the open() function which allows the creation of /or reading of files so long as you know a valid path. Once you've gone to all that effort of hacking Python to be... well, not Python - why stick with the language? No answer for you. But if people aren't willing to remove that functionality, or limit it globally in the internal interpreter, then there's no way to lock things down. I think the biggest problem is that everyone is looking for an easy answer and there simply isn't one. Agreed. ...and then you lose me entirely. Sorry, but until such time as .blend is a standard file format, how exactly do you expect people to fill a basic scene? If it's open content, it is almost invariably available in an OBJ format. Collada is picking up speed, but it is not there yet. Hell, The web-comic artist-to-be I talked about in an earlier email gets a majority of her art from Poser props exported as, you guessed it, OBJ files. I think there's a difference between users who want inter-program operation and users who want to do everything inside one software package. Most of the hobbyist Blender users I know (most, not all) do EVERYTHING inside Blender and never round-trip to external software. The web-comic artist you spoke of would not be an entry-level user in my opinion; by the time he's ready to do stuff like that he's also ready to make the decision to unlock the additional functionality and drop the security barrier. But until that point, while he's learning the software and getting to grips with what's possible? No, I don't think he needs an interchange format. This is indeed a possibility, but given that the general environment here seems adverse to anything resembling a large amount of effort to securing Blender (a viable understandable position); I think this is another non-starter solution. Especially when there is no greasy wheel needing a kick. We're already facing outright hostility to the effort required for a basic on/off solution to the problem from core developers. I don't think it is a long bow to draw expecting the moving all standard import/export plugins to C idea to be tossed aside almost immediately. Agreed, but if the people interested in security aren't interested in writing C-language trusted operators to lock down the system then they must not be that interested in security, right? OK, have you actually read Campbell's emails to the list on this? It is *trivial* to hide the real intent of Python code, /especially/ from automated code introspection functionality. Virii make it through the filters designed by multi-million dollar companies *dedicated* to this task. It took Campbell not even a day after reading how two research papers suggested securing Python to find away around it; even if it takes your average malware author four times the amount of time to get around our open-source filter - he'll have it done in under a week tops. Yes, I did read Campbell's mails. But ANYTHING that's done security-wise can be cracked! It's not about trying to lock down the system 100% perfectly -- the only system that's locked down is the one that's unplugged and locked away from humans. And Blender is worse off from the get-go because all discussion about security in it is done on an open forum, and the code is easily perused for holes. I was trying to suggest that a compromise might be reached where a bit of introspection were done. As exploits are discovered you could update the exploit list in Blender to recognize new code strings. No, it won't catch everything, but nothing will. Anyway, retracted. Again, back to dismissing the problem through characterising anyone not skilled in computer technology as an idiot. Opening a file in Photoshop or GIMP does not make make one vulnerable to exploits. Neither does opening a file in MyPaint, WinAmp, Google SketchUp, or Wings (reading across a row of shortcuts on my desktop). Opening a potentially dangerous file in OpenOffice (next row of shortcut icons) explicitly asks me whether I wish to enable the possibly dangerous scripts. This is standard behaviour for applications where you view or edit something. Most applications are built to cater for the fact that end-users differentiate between running a program and opening a document. Trying to ignore this does not change the fact. I'm doing nothing of the sort. I myself have been tired and downloaded the wrong thing from the wrong site and ended up with a bricked XP machine more than once. I also once ended up with a virus just for having MSN messenger installed,
Re: [Bf-committers] Texture assignment workflow is confusing
Actually this I like this idea too Doug(already mentioned by brecht actually) and I think the only problem left is where the texture properties will be. I would prefer being able to see both material+texture properties at the same time as opposed to the current system(Well, OK you can have two properties areas, but you know what I mean)Maybe this can work quite well with the new subdivide system, similar to the quad view in the 3D viewport. Like, the properties area subdivides in two when the user presses the texture button next to the component textured, and one sub-area becomes the texture context. But that still leaves the texture panel functionality in modifiers/sculpt tools as a problem + it is likely that such a solution will require the user to resize the area to see all the settings. Anyway, just my 2 cents again. Texture stacks are not useless even in a per shading component basis. I may want 2 textures to influence my normal, then bake them together in a 3rd texture for example. This is not uncommon! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Charles Wardlaw wrote: No answer for you. But if people aren't willing to remove that functionality, or limit it globally in the internal interpreter, then there's no way to lock things down. Agreed 100%. The issue, as I keep repeating, is that the ideal solution is that the scripts needing access to file systems, network, etc can get it and those that don't (such as rig constraints and the like) do not. Python, by design, makes this impossible. Other language options do not. I think there's a difference between users who want inter-program operation and users who want to do everything inside one software package. Most of the hobbyist Blender users I know (most, not all) do EVERYTHING inside Blender and never round-trip to external software. The web-comic artist you spoke of would not be an entry-level user in my opinion; by the time he's ready to do stuff like that he's also ready to make the decision to unlock the additional functionality and drop the security barrier. But until that point, while he's learning the software and getting to grips with what's possible? No, I don't think he needs an interchange format. Actually, I've worked with HER to get her at least familiar with the Blender interface and *trust me* she is an entry-level user. Knowing that she can get a prop out of Poser by following a set of steps (she does not understand) does not mean she knows what a rig script is and/or how it can be abused to compromise her computer. Hell, she would probably think I was being dirty using the term compromise your computer. We shouldn't confuse being able to import a file (or other simple operations) with understanding how things work. Agreed, but if the people interested in security aren't interested in writing C-language trusted operators to lock down the system then they must not be that interested in security, right? Agreed. But said code needs to be accepted by the core development team. If they hold the view that the operators should stay in Python for easy modification (or any other reason really); any effort put into making them C-code is just going to wasted isn't it? Yes, I did read Campbell's mails. But ANYTHING that's done security-wise can be cracked! It's not about trying to lock down the system 100% perfectly -- the only system that's locked down is the one that's unplugged and locked away from humans. And Blender is worse off from the get-go because all discussion about security in it is done on an open forum, and the code is easily perused for holes. False claim there. A wide variety or studies have shown that opening security code up for public inspection leads to quicker resolution of problems and/or finding out if a solution is going to fail by design (as opposed to simply a bug in the implementation). I was trying to suggest that a compromise might be reached where a bit of introspection were done. As exploits are discovered you could update the exploit list in Blender to recognize new code strings. No, it won't catch everything, but nothing will. Anyway, retracted. I can see where you are coming from, but it is not a feasible solution. The line quoted by Martin is a basic version of getting around it. I cold base64 encode a string then use eval, I could make a round about function to do it, etc. The issue isn't the WAY it is being done - it is that the functionality is allowed at all in a Python constraint. I can't speak to the paint programs but I know that buffer exploits have allowed code to be executed from within MP3 files in the past. No scripting there, but they were a security risk. And Winamp can play WMA, right? Those can contain all kinds of crap that gets run through the Windows Media layer and can install software, pop up IE windows, etc. How many home users who think in terms of documents, not programs or formats, can differentiate between WMA and mp3 when the icons are similar? I've known a lot of people who asked me to help them figure out why WMA files wouldn't play on their MP3 player. Buffer overruns are a BUG. The current security issues are a result of mismatched design. Blender developers want to run Python in it's rigs/constraints. Python developers want the namespace browsing features (that are a foundational element of their language) and they want to keep unsecure functions (like the file open() function) as a part of the raw, always available functionality offered by their runtime. If Blender wants to add security, one of these two must give. The issue is a result of design not implementation. Like DRM, the requirement of client-side access to resources post decryption conflicts with the desire for the publisher to stop people from playing the game without their authorisation. One side has to give and, by dint of the fact the client has to be able to play the game, the publisher's desire for a lock-down on content is usually the one that
Re: [Bf-committers] Security gets in the way
Raul Fernandez Hernandez wrote: Is time to end up this security discussion: paperware is very beautiful but never leave the planification phase. The pro-security team could work on a prototype that could shut up the rest of us that think this discussion is getting in the way, meanwhile, the rest of us could continue improving blender. Are you speaking for the Blender development team or just yourself? Serious question as I'd like to know if the opinion that adding security is not part of improving Blender is shared at the top level. After all, if Ton (for example) doesn't want there to be a security option - there simply isn't going to be one as it will never get into trunk. There is no point makling a prototype if the end-result is already predetermined as we don't want it. Don't get me wrong, I have no intention of discrimination , I think the fact that english is not my way of thinking could lead to this. I was speaking for myself , splitting in pro-security and the rest is very natural when a discussion arise, is nothing bad, and when I was referring to the rest of us could continue improving blender I didn't mean that working in security was not improving blender, I mean: the rest of us could continue working in their projects in blender. I think a working patch or prototype is way better than a long discussion that sometimes get out of its path, nothing more. Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture assignment workflow is confusing
I only use Blender but I was wondering if the other 3d packages have found a good way to handle this texture/materials problem? Could we incorporate some good ideas this way? Why reinvent the wheel? Does anyone have a favorite other system? How does it work? I am not putting down the other ideas given so far, just hoping to find all the options before we pick the best. -- Douglas E Knapp 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] Trusted Blender Content Repository (was Re: Security gets in the way)
On Thu, Apr 29, 2010 at 12:31 PM, Kevin Roy kin...@gmail.com wrote: Hello, Thu, 29 Apr 2010 11:10:39 +0400 Ruslan Merkulov r.merku...@gmail.com wrote: 2) Create some sort of official content and scripts repository for Blender with some sort of approving scheme. Maybe create an add-on for Blender to download and install content approved by community and/or developers. So, it boils down to a) educating users about security awareness, b) creating a network of trust and incidentally making finding and installing safe content easier. I recently have this kind of conversation with a developer who create a game with the blender game engine and didn't know where to share and publish it. All I was able to answer to him was to publish it in the blenderartists forums and put a link in the wiki. But blender contents in the forums are quite dispersed and wiki Plugins section needs heavy maintenance IMO. It would be awesome to have such an apt-like repository with scripts, games or model templates and installing them directly from inside Blender. If there is a task for it, I would likely give my help as I am mainly interested in python script development. Cheers --- Kevin 'kiniou' Roy http://blog.knokorpo.fr I have alway thought this was a good idea. All the elements that are not core should be in one big official repository. This would also lessen the chances of getting blender viruses and the like and make blender much more secure without having to do stuff like sand-boxing python. I for one would love to have 2 download options. One, as we have now, to get the program and a second DVD download of resources. Then in addition to that we could have a very nice resource site with a SQL backside. The only downside I see to this is paying for the internet pipe and the server. -- Douglas E Knapp 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] [28485] trunk/blender/intern/guardedalloc/ intern/mallocn.c: reverting 28469, there is no use in using a long, while the allocation functions only accepts an int.
Hi, ideasma...@gmail.com (2010-04-28 at 1015.26 +0200): Revision: 28485 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=28485 Author: campbellbarton Date: 2010-04-28 10:15:26 +0200 (Wed, 28 Apr 2010) Log Message: --- reverting 28469, there is no use in using a long, while the allocation functions only accepts an int. - only wastes 4 bytes per alloc. Also would be most correct to use size_t Oh, I thought you were just solving a problem with the struct, not that mallocn.c still is 64 bit uncompatible. GSR ___ 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 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 Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
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 m...@juddrobotics.com wrote: From: Michael Judd m...@juddrobotics.com Subject: Re: [Bf-committers] Security gets in the way To: bf-blender developers bf-committers@blender.org 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 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 -- Michael Judd 853 New Cleveland Rd Gumdale, Qld 4154 Email: m...@juddrobotics.com Phone: +61 (0)7 32452864 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Ok it seems we are getting nowhere fast on this, so to address the original issue, have it off by default as that is what seems to be causing the most troubles, yet keep it there for those who need it (ie paranoid IT people :) ), as in a studio you will mainly be using internal scripts for like rigs and such not much from the external world also to show the danger to new users put a warning on the download page in nice red letters at the top all of this is done until a suitable option is available, and dropping python all together is certainly not a viable alternative now can this argument please end? -- Michael Fox Developer and user of Blender3d www.blender.org http://mfoxdogg.googlepages.com mfoxd...@gmail.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Raul Fernandez Hernandez wrote: Don't get me wrong, I have no intention of discrimination , I think the fact that english is not my way of thinking could lead to this. I was speaking for myself , splitting in pro-security and the rest is very natural when a discussion arise, is nothing bad, and when I was referring to the rest of us could continue improving blender I didn't mean that working in security was not improving blender, I mean: the rest of us could continue working in their projects in blender. OK, I apologise for misinterpreting you. The lack of clarity as to what will or will not be accepted by core development perhaps makes me read too much into the posts by main developers :) I think a working patch or prototype is way better than a long discussion that sometimes get out of its path, nothing more. The issue I have is that I (or someone else) could put ALOT of work into fixing this without it being accepted into core because they are not interested in what it takes. Security is not like a new operator or constraint. Like the UI refactor - it will affect almost everything in Blender in some way. The amount of work needed even for a basic prototype is substantial. To use a recent example, how do you think a developer would have felt if they put together the Blender 2.5 UI refactor prototype if they knew Ton was against it? I know I wouldn't have bothered. Not because I don't think it is a great feature, but by the very fact it touches almost everything (like security will); it would be impossible to keep up with Blender development through patching a local installation. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Michael Fox wrote: Ok it seems we are getting nowhere fast on this, so to address the original issue, have it off by default as that is what seems to be causing the most troubles, yet keep it there for those who need it (ie paranoid IT people :) ), To be honest, I think the reason it is not getting anywhere is two-fold. Firstly, the default off /solution/ that is proposed is *not* a solution. It's like making entering a password optional. Unless it is by default *on*, the people most vulnerable to an attack are going to be those that don't turn it on. as in a studio you will mainly be using internal scripts for like rigs and such not much from the external world OK, and when rigs do come in from the outside world, like in the recent Durian townsfolk sprint, we *know* that those most experienced in Blender will check them for malicious scripts and/or only open them on machines locked out of the network, right? We still haven't got an answer on that. I think that is pretty telling. also to show the danger to new users put a warning on the download page in nice red letters at the top all of this is done until a suitable option is available, and dropping python all together is certainly not a viable alternative Warning, I am happy to have. Without cooperation from the Python development team though, keeping Python is not a viable alternative either. Something might come out of PyPy (currently they still have all or nothing security, not context-by-context restriction) which will make this all moot. now can this argument please end? I'm simply replying to emails on the subject. It's not like this has been going for a week and debate on controversial subjects like this are not going to be solved by asking people to just agree. Should one of the core devs ask me to stop mailing on the subject, I will of course do so - it is, after all, their opinion on the matter I am trying to ascertain! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
http://www.philhassey.com/blog/tinypy-ideas/ Embed tinypy * Objective: sandbox tinypy and then (as in lunatic python) build a python module that uses tinypy for safe execution of “unknown” code it's just an idea at the moment and not implemented but this sounds interesting. :) tinypy could be used for drivers in the long term. in the short to mid term there doesn't seem to be an easy and secure solution but in the long term all the this is impossible with python seems to be wrong to me. to me it looks like in 2-3 years the whole situation will look different (pypy, tinypy,...) and there will be feasible solutions. On Fri, Apr 30, 2010 at 2:09 AM, Martin Poirier the...@yahoo.com wrote: There's still very little doubt that this will be the solution that is going to be adopted (in the short to mid term at least). Martin --- On Thu, 4/29/10, Benjamin Tolputt btolp...@internode.on.net wrote: From: Benjamin Tolputt btolp...@internode.on.net Subject: Re: [Bf-committers] Security gets in the way To: bf-blender developers bf-committers@blender.org Received: Thursday, April 29, 2010, 7:46 PM Martin Poirier wrote: 0. Keep current features, switch from default on to default off. In which case you may as well not have the feature at all. The people most vulnerable to a malware attack from ANY vector are those that would not know to turn security on. Not to mention the fact that security of an on/off variety pretty much hoses any chance of decent rigs whilst having security enabled. As I've mentioned, it's like disabling macros in Office and it not allowing you to use bold fonts and paragraph spacing. Sure you can get around it, but it is not what one would consider a good solution ___ 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] Security gets in the way
Apathy can also result in people giving up trying to convince others of the wrong solutions. It's a double-edge sword. Benjamin Tolputt wrote: Martin Poirier wrote: There's still very little doubt that this will be the solution that is going to be adopted (in the short to mid term at least). That doesn't mean I shouldn't disagree with it ;) Apathy results in poor solutions because people give up trying to convince people of the right ones. ___ 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
Of course the this is impossible with python can be wrong in the long term; who know what direction python will evolve in the next 2-3 years. But trying to find a python solution right now, with what we have, is impossible. I have to agree with what someone posted earlier: if someone is convinced this (a secure solution) can be done with the existing Python 3.1, they need to code up a proof-of-concept to shut up everyone who says it can't be done. Otherwise everyone is just filling up a useful mailing list with spam. horace grant wrote: http://www.philhassey.com/blog/tinypy-ideas/ Embed tinypy * Objective: sandbox tinypy and then (as in lunatic python) build a python module that uses tinypy for safe execution of “unknown” code it's just an idea at the moment and not implemented but this sounds interesting. :) tinypy could be used for drivers in the long term. in the short to mid term there doesn't seem to be an easy and secure solution but in the long term all the this is impossible with python seems to be wrong to me. to me it looks like in 2-3 years the whole situation will look different (pypy, tinypy,...) and there will be feasible solutions. ___ 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 didn't mean that to come across as a personal attack, Benjamin. I'm just pointing out that just because someone has an idea, that doesn't mean it's the right idea. Ken Hughes wrote: Apathy can also result in people giving up trying to convince others of the wrong solutions. It's a double-edge sword. Benjamin Tolputt wrote: Martin Poirier wrote: There's still very little doubt that this will be the solution that is going to be adopted (in the short to mid term at least). That doesn't mean I shouldn't disagree with it ;) Apathy results in poor solutions because people give up trying to convince people of the right ones. ___ 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] Security gets in the way
Ken Hughes wrote: I didn't mean that to come across as a personal attack, Benjamin. I'm just pointing out that just because someone has an idea, that doesn't mean it's the right idea. Ken Hughes wrote: Apathy can also result in people giving up trying to convince others of the wrong solutions. It's a double-edge sword. Don't worry mate, I got your meaning, even if it didn't quite read that way the first time :) I honestly think the debate is going to fizzle out regardless, because the real decision makers are remaining silent. No solution we come up with, regardless of what we think about, is going to make it into Blender without the core Blender developer's say so. Regardless of the animation/motivation of all sides on this debate, the only concrete thing to have come out of it is Campbell adding a switch to the network render. That's it. It's better than the default security to off I am arguing against, but everyone agrees it is not really a fix. Until there is an official position on the matter, ALL sides of the debate are just shouting into the wind. Sad but true. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
8. Worry about it when something actually happens and you have a real case to confront, rather than hyperbole. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Roger Wickes wrote: 8. Worry about it when something actually happens and you have a real case to confront, rather than hyperbole This is insulting. The developers have already acknowledged this is an issue. That is why there is the default on security in Blender now. Waiting for someone to be compromised when the problem is *known* is callous and irresponsible. Saying that we delay a solution until we have time to look into it properly is practical. Saying we shouldn't do anything until someone is hurt by it is lazy and unethical. Yeah, we knew there was a problem with the brakes. But we thought we'd worry about it when something actually happened and had a real case to confront ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture assignment workflow is confusing
On 30/04/2010 3:49 a.m., Knapp wrote: I only use Blender but I was wondering if the other 3d packages have found a good way to handle this texture/materials problem? Could we incorporate some good ideas this way? Why reinvent the wheel? Does anyone have a favorite other system? How does it work? I am not putting down the other ideas given so far, just hoping to find all the options before we pick the best. For those who have just joined my concept is to move the texture assignment to the point of control/use/influence when setting up a material in order to create a semantic/logicial link between action and affect : http://www.pasteall.org/pic/show.php?id=2989 Note: I dislike submitting ideas and saying they were influenced by the big boys, because I find it sometimes elicits a we don't want to copy response, and forces us to reinvent the wheel due to the pride of being independent and creative. However, pride aside, I agree that looking at how others have solved a problem, and then improving on their solutions is one of the best methods of development, its not revolutionary, but nor were puffer-fish, they evolved from something way less exciting. I'll outline the two softwares that I have used that give any real control over multiple textures, I am curious what great softwares others have used that solve these issues. But to sum it up I found the easiest to use ones use a socket type system. The non-flexible ones with nice results (cad rendering packages) give few if not no options so I just won't mention them. *Photoshop 3D tools,* They use a limited socket type system, either a colour, or a single image per value of influence. I.e. you can choose an image for the reflection channel, colour channel, spec channel Super easy, pretty limited, but limited in order to be compatible with real-time 3D content in PDF's etc... Since you are in photoshop you can edit the images, and this is where you can add layers and overlay options etc... to get what you want in terms of further control. *Maya (it's been a while, this is from memory)* Uses something in-between what I am suggesting and the photoshop approach. Just like the Blender 2.5 materials panel; each material or setting is broken up into a sub panel that can be turned on/off for any one effect (incredibly close to the current Blender layout). However, they use a socket type texture/node/material input to alter various settings that cannot be controlled simply by a slider or colour picker. I believe their implementation is even used to plug in 3rd party Plugins like SSS, Ramp, and fresnel effects to the various channels etc... (not just textures). This linked approach also creates a hypergraph (nodes) structure. I had no idea how to use that then so ignored it. My biggest annoyance with the Maya system was getting lost once a texture has been added, as it dropped you somewhere else in the interface that you did not expect (a challenge we would need to overcome, but one I think is possible). I am glad brecht suggested this or something similar, as he's pretty on to it, especially when it comes to getting large numbers of fans. If this approach is preferred, and is backed up by a development goal from the decision makers (If Ton sanctions exploring it it etc..), I will be willing to work through interface issues with Matt, and William (these are the two people focusing on interface correct?). The main interface issues to overcome as I can see it are. ** Materials - how to keep these tabs clean from fluff ** Texture application settings - Where and how do you edit these settings that are unique to each material (not to the texture) ** Texture settings - the traditional 2.4x datablock, how do you get to this and back again from a material, and a potential intermediate step ** Adding and mixing - The current system lets you add and mix multiple textures, how can this be easily and logically done? (nodes?, stacks?...) ** extending into the future... Plugins Etc - I think some of this will come for free if this is a natural step towards nodes everywhere. I think there are no issues that cannot be overcome. and I think that old textures can be loaded into a new interface with full compatibility. Someone let me know if this warrants further development and I will look at creating a more detailed interface flow scenario. By trade i'm an Industrial Designer, so can look at usability and interaction, I'm not a coder unfortunately so cannot help there. Cheers -- Doug Ollivier *C:*+64 (0)27 412 0807 *P:*+64 (0)3 980 7197 *E:*d...@doug.org.nz *W:*http://doug.org.nz ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Ken Hughes wrote: Of course the this is impossible with python can be wrong in the long term; who know what direction python will evolve in the next 2-3 years. But trying to find a python solution right now, with what we have, is impossible. Bingo. Glad I'm not the only one saying this. We may not agree on the final solution (or that we choose to not have one), but I'm glad that the technical realities are being agreed on. The most frustrating thing in any debate isn't being disagree with on the final answer, it is having to correct people on the facts that make up the debate foundation. Case in point - it is impossible with current versions of Python to secure the loading/rendering of a Blender scene whilst also allowing Python to be embedded in said scene (in constraints, rigs, etc). This is a *fact* given current implementations of Python. I have to agree with what someone posted earlier: if someone is convinced this (a secure solution) can be done with the existing Python 3.1, they need to code up a proof-of-concept to shut up everyone who says it can't be done. Otherwise everyone is just filling up a useful mailing list with spam. Another good point. I've been browsing the code whilst the debate has raged and the amount of work to move Blender to any other language is phenomenal! If a solution using the standard Python library can be found - I'd be VERY happy to use it. I am not saying Python is bad - it is a very good, mature, and flexible language/platform. It's a little heavy for embedding in my projects (and there are thread locking issues); but I use it all the time for data processing tasks. That said, it is *by design* unable to be secured in the way Blender requires if one is going to allow Python expressions in a scene file. I doubt anyone is going to want to look at replacing Python unless there is some nod from the core developers as to it being allowed consideration for trunk. However, a patch to Blender that allows it to be secured whilst still using Python would likely be accepted without much hassle at all. It would be a bug fix as compared to an application-wide refactor. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
That was covered by 5. People concerned about malicious scripts already have options to run scripts from the wild in a secure fashion now using a virtual machine or a locked down user on a decent OS. People not concerned about security have probably already been pwned anyway. 5 is a valid choice. Roger Wickes wrote: 8. Worry about it when something actually happens and you have a real case to confront, rather than hyperbole. ___ 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] Texture assignment workflow is confusing
Awesome, was curious how light-wave did it. They are all seeming relatively similar with minor differences in approach. Any wild cards out there from strange softwares etc? On 30/04/2010 1:40 p.m., Daniel Salazar - 3Developer.com wrote: Ive suggested this type of texture managing in the past inspired on Lightwave where you can assign a texture or a texture stack to each value Material properties with a T icon to launch texture stack http://www.except.nl/lightwave/hdr/images/Surface_notgood_sm.png Texture Stack http://www.robinwood.com/Catalog/Technical/LightwaveTuts/LWPacks/StainedGlass/SGlassImages/SGlass19B-LayerStack.jpg nice... Daniel Salazar www.3developer.com On Thu, Apr 29, 2010 at 7:32 PM, Doug Ollivierd...@doug.org.nz wrote: On 30/04/2010 3:49 a.m., Knapp wrote: I only use Blender but I was wondering if the other 3d packages have found a good way to handle this texture/materials problem? Could we incorporate some good ideas this way? Why reinvent the wheel? Does anyone have a favorite other system? How does it work? I am not putting down the other ideas given so far, just hoping to find all the options before we pick the best. For those who have just joined my concept is to move the texture assignment to the point of control/use/influence when setting up a material in order to create a semantic/logicial link between action and affect : http://www.pasteall.org/pic/show.php?id=2989 Note: I dislike submitting ideas and saying they were influenced by the big boys, because I find it sometimes elicits a we don't want to copy response, and forces us to reinvent the wheel due to the pride of being independent and creative. However, pride aside, I agree that looking at how others have solved a problem, and then improving on their solutions is one of the best methods of development, its not revolutionary, but nor were puffer-fish, they evolved from something way less exciting. I'll outline the two softwares that I have used that give any real control over multiple textures, I am curious what great softwares others have used that solve these issues. But to sum it up I found the easiest to use ones use a socket type system. The non-flexible ones with nice results (cad rendering packages) give few if not no options so I just won't mention them. *Photoshop 3D tools,* They use a limited socket type system, either a colour, or a single image per value of influence. I.e. you can choose an image for the reflection channel, colour channel, spec channel Super easy, pretty limited, but limited in order to be compatible with real-time 3D content in PDF's etc... Since you are in photoshop you can edit the images, and this is where you can add layers and overlay options etc... to get what you want in terms of further control. *Maya (it's been a while, this is from memory)* Uses something in-between what I am suggesting and the photoshop approach. Just like the Blender 2.5 materials panel; each material or setting is broken up into a sub panel that can be turned on/off for any one effect (incredibly close to the current Blender layout). However, they use a socket type texture/node/material input to alter various settings that cannot be controlled simply by a slider or colour picker. I believe their implementation is even used to plug in 3rd party Plugins like SSS, Ramp, and fresnel effects to the various channels etc... (not just textures). This linked approach also creates a hypergraph (nodes) structure. I had no idea how to use that then so ignored it. My biggest annoyance with the Maya system was getting lost once a texture has been added, as it dropped you somewhere else in the interface that you did not expect (a challenge we would need to overcome, but one I think is possible). I am glad brecht suggested this or something similar, as he's pretty on to it, especially when it comes to getting large numbers of fans. If this approach is preferred, and is backed up by a development goal from the decision makers (If Ton sanctions exploring it it etc..), I will be willing to work through interface issues with Matt, and William (these are the two people focusing on interface correct?). The main interface issues to overcome as I can see it are. ** Materials - how to keep these tabs clean from fluff ** Texture application settings - Where and how do you edit these settings that are unique to each material (not to the texture) ** Texture settings - the traditional 2.4x datablock, how do you get to this and back again from a material, and a potential intermediate step ** Adding and mixing - The current system lets you add and mix multiple textures, how can this be easily and logically done? (nodes?, stacks?...) ** extending into the future... Plugins Etc - I think some of this will come for free if this is a natural step towards nodes everywhere. I think there are no issues that cannot be
Re: [Bf-committers] Security gets in the way
Michael Judd wrote: People concerned about malicious scripts already have options to run scripts from the wild in a secure fashion now using a virtual machine or a locked down user on a decent OS. And as I said before, it is the people that don't know to be concerned that need this the most. Anyone likely to be using your locked down decent OS and/or has the skills to setup a virtual machine (ignoring the performance problems that entails) is unlikely to be downloading unsecure scene of the Internet. Remember, even a concientious user who scans the .blend file with an anti-virus is going to still be compromised. People not concerned about security have probably already been pwned anyway. People in the graphics industry probably already have Max or Maya, so we shouldn't bother making Blender better. Businesses needing Unix probably already have contracts with IBM, so we shouldn't bother making Linux better People growing up in underprivileged areas are likely to never amount to anything, so we shouldn't bother helping them better themselves. What a wonderful world that would be, eh? ___ 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 Thu, 4/29/10, Benjamin Tolputt btolp...@internode.on.net wrote: I honestly think the debate is going to fizzle out regardless, because the real decision makers are remaining silent. The topic was reopened following a conversation between decision makers on IRC. Both of which as well as others have participated in the discussion that followed. To be honest, the decision was pretty much already taken, people just didn't noticed. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture assignment workflow is confusing
Doug Ollivier wrote: Any wild cards out there from strange softwares etc? hmm... just blender :) -- Christopher Cherrett ccherr...@openoctave.org http://www.openoctave.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Martin Poirier wrote: The topic was reopened following a conversation between decision makers on IRC. Both of which as well as others have participated in the discussion that followed. To be honest, the decision was pretty much already taken, people just didn't noticed. Would you be so kind as to let us know what that decision was? After all, not all of us are able to participate in the IRC chats. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
Best bring this up next meeting and come to some consensus. I wasn't in IRC for the decision either :) However I'm going away this weekend, can make it for the next one though (May 9th). Don't thinik 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. On Fri, Apr 30, 2010 at 6:25 AM, Benjamin Tolputt btolp...@internode.on.net wrote: Martin Poirier wrote: The topic was reopened following a conversation between decision makers on IRC. Both of which as well as others have participated in the discussion that followed. To be honest, the decision was pretty much already taken, people just didn't noticed. Would you be so kind as to let us know what that decision was? After all, not all of us are able to participate in the IRC chats. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
