something else came to my mind. the problem of the OP was that rigs
didn't work anymore and he at first had no idea why, which did cost
him a lot of time...
what about keeping the global security setting just like it is at the
moment but instead of simply ignoring drivers when the setting is OFF,
As a subscriber to this list and long time blender user I thought I
would add my opinion.
I for one welcome the check box to dissable running python scripts on
open and the trusted source
override in the open blend file dialog box.
With my setting set to OFF, not to run python scripts on laun
I think the complaint was that as is pypy was all or nothing
sandboxing. I was proposing writing a pypy hosted interpreter that
had the specific features required. Too bad I have other fish to fry
or I'd build a prototype
On Apr 30, 2010, at 10:07 PM, Tom M wrote:
> Jason,
>
> there is
Tom M wrote:
> there is already a sandbox version of pypy.
>
> http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
>
The sandbox described in that page is not exactly what he is talking
about. That is a Python-wide sandbox that shunts all sensitive
functionality (file access, sockets, OS opera
Ruslan Merkulov 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 and requires the least amount of changes in Blender's
> and third party plugins' code. It seems to work for Mozilla
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-committ
On Fri, Apr 30, 2010 at 7:39 PM, Benjamin Tolputt 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 interpr
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
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
> th
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 t
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 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 thi
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, o
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,
I wonder how Sketchup deals with this issue with their embedded ruby...
On 4/30/10, 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 aw
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
Benjamin Tolputt wrote:
> 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
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 w
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.
>
Woul
--- On Thu, 4/29/10, Benjamin Tolputt 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 parti
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 th
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.
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 sayin
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
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
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
> """
>
Not a bad idea, though not standard Python. Honestl
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
>>
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 doubl
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
conv
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
.
>
> Martin
>
> --- On Thu, 4/29/10, Benjamin Tolputt wrote:
>
>> From: Benjamin Tolputt
>> Subject: Re: [Bf-committers] "Security" gets in the way
>> To: "bf-blender developers"
>> Received: Thursday, April 29, 2010, 7:46 PM
>> Mart
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
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
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 wrote:
> From: Benjamin Tolputt
> Subject: Re: [Bf-committers] "Security" gets in the way
> To
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 s
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
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 r
from default on to default off.
>
> Martin
>
> --- On Thu, 4/29/10, Michael Judd wrote:
>
>
>> From: Michael Judd
>> Subject: Re: [Bf-committers] "Security" gets in the way
>> To: "bf-blender developers"
>> Received: Thursday,
0. Keep current features, switch from default on to default off.
Martin
--- On Thu, 4/29/10, Michael Judd wrote:
> From: Michael Judd
> Subject: Re: [Bf-committers] "Security" gets in the way
> To: "bf-blender developers"
> Received: Thursday, April 29, 2010,
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
> 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, mean
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
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,
>
> 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
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 b
> 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 arou
I have to say this to lighten the situation:
I guess the end result is that windows is crap, if you need security use linux!
lolololol!!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
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 b
--- On Thu, 4/29/10, Charles Wardlaw 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
Again a discussion that turned into a real mess.
I don't see the point really. The best security is still your brain and
not a button which says "make my computer secure" or whatever.
You are downloading lots of different file types every day. Just don't
load files from sources you don't trust.
> *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
> Python does not allow a single virtual machine to allow some parts of
> code to run in a secure, module-limited subset of the execution context
> (as would be needed to limit rig expressions to secure subsets) whilst
> allowing other blocks of code to run relatively unsecured (like that
> require
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
There are couple of things that can be done to improve the situation:
1) Include a warning message in the splash screen in bold letters
about downloading and opening random .blends and scripts from the
Internet.
2) Create some sort of official content and scripts repository for
Blender with some s
Harley Acheson wrote:
> I am a Blender noob, a long-time developer (25 years but very little with C),
> but I spend my days as a network administrator for a large-ish network (650
> users, 700 computers). So you would naturally think that I would be in the
> “theoretical IT types” in favor of hi
Hello,
Sorry, but I couldn’t resist weighing into this debate because I feel I have a
fairly
unique perspective on this security issue. I am a Blender noob, a long-time
developer (25 years but very little with C), but I spend my days as a network
administrator for a large-ish network (650 use
Charles Wardlaw wrote:
> But there's a difference between that and what Blender's currently
> doing: that "security" feature is opt-in. Blender's is not, but in my
> opinion should be.
>
Again I come back to the user-base of the applications in question. How
many people do you know outside
Hey Guys,
Well I only saw a few snippets of this thread and didn't wanna read it
completely since the discussion was going pointless with "lets replace
python with some other scripting language" . Replacing or restricting sounds
completely lame when the whole industry is moving towards python to h
--- On Wed, 4/28/10, Charles Wardlaw wrote:
> I'm surprised that nobody has mentioned the simple solution
> of
> disallowing automatic scripts and scripted constraints from
> accessing
> the os and sys modules (perhaps limiting imports to only
> bpy).
That's because it doesn't work. Anybod
> According to the Maya documentation, there is a check-box that allows
> you to disable the execution of "script nodes" when opening the file.
> This would indeed be a "security measure" available and there has been
> no uproar on it that I've heard of.
It's actually not a security measure, altho
?
Best,
AMR
Sent from my Verizon Wireless BlackBerry
-Original Message-
From: Benjamin Tolputt
Date: Thu, 29 Apr 2010 11:45:20
To: Benjamin Tolputt; bf-blender
developers
Subject: Re: [Bf-committers] "Security" gets in the way
Sorry if this is a repost - I sent this hours ago
--- On Wed, 4/28/10, Benjamin Tolputt wrote:
> From: Benjamin Tolputt
> Subject: Re: [Bf-committers] "Security" gets in the way
> To: "bf-blender developers"
> Received: Wednesday, April 28, 2010, 8:31 PM
> Charles Wardlaw wrote:
> > The simple an
Sorry if this is a repost - I sent this hours ago and it never turned up
in my inbox (unlike others I sent more recently). Ignore this if the
mailing list already has a copy.
Note that I am replying to all of last night's posts - Matt's is just
the last in the list & he hits most bases I want to c
Charles Wardlaw wrote:
> The simple answer is: they don't. If Maya tried to add security settings to
> files you can bet your own child the uproar would be heard into space, and
> they'd roll back the change pretty quickly.
>
According to the Maya documentation, there is a check-box that allo
joe, I believe, it's possible write a blender python script that will
read your private data and send it to author's email and do all sorts
of other evil stuff. And if you have "Auto-run scripts" turned, all it
takes is a download a blend file, run it and that's it.
On Thu, Apr 29, 2010 at 4:21 AM
Why do we need these "security" features anyway? It's not like there
aren't tons of exploits that could be taken advantage off anyway.
Blender is a producton 3d app, not a web browser.
Joe
On Thu, Apr 29, 2010 at 2:09 AM, Charles Wardlaw
wrote:
>> Blender isn't the only 3d app to use python as e
> Blender isn't the only 3d app to use python as embedded language. I
> wonder how Maya and Houdini deal with these kinds of problems? And not
> only 3d packages encounter such issues - Google App Engine for example
> restricts usage of some python modules.
The simple answer is: they don't. If May
Blender isn't the only 3d app to use python as embedded language. I
wonder how Maya and Houdini deal with these kinds of problems? And not
only 3d packages encounter such issues - Google App Engine for example
restricts usage of some python modules.
___
B
My suggestion is that for those who are deeply concerned about the
security issue is to investigate how to switch to using pypy as an
option.
It is fully sandboxable etc. Those who need 'security over usability'
can have it. It looks like performance is approaching CPython for
many cases and onc
Sorry, I mean network games must use a secure game engine.
> Date: Wed, 28 Apr 2010 23:28:53 +0200
> From: horac...@gmail.com
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] "Security" gets in the way
>
> On Wed, Apr 28, 2010 at 10:52 PM, Makslane Rod
> The very big problem now is that Blender is not functional by default
> - very important parts of it do not work after you install it. Your
> own files *don't work*. This is a very stupid situation to be in, and
> needs to be changed.
Well said.
~ C
On Thu, Apr 29, 2010 at 2:31 AM, wrote:
> What ?! how come the discussion started with "current blender defaults are
> getting in the way with production" which I totally agree and switched to
> "Let's replace Python with something else" ???
Yes, this is getting silly, and I think is representat
On Wed, Apr 28, 2010 at 10:52 PM, Makslane Rodrigues
wrote:
>
> I'm looking the Blender as a game creator, not just a 3D tool.A game creator
> tool must be secure.
why must a game creator be secure? for the webplugin security of
course would be important but for standalone games it doesn't matt
I'm looking the Blender as a game creator, not just a 3D tool.A game creator
tool must be secure.
Just my 2 cents
Makslanehttp://game-editor.com
_
Mude seu visual no Messenger e divirta-se com se
I hope I'm wrong and is something I have missed from the "Security"
discussion but is leading to dangerous thougths Dropping python?!?!?!
Python support has being one of the best steps Blender has ever made, even
before the industry standard packages start considering python (when each
one imp
n to be focused on a Python solution.
> >
> > regards,
> >
> > -idesisnery
> >
> >
> >
> >> Cheers
> >>
> >> Remo
> >>
> >> > -Original Message-
> >> > From: bf-committers-boun...@blender.o
>
> regards,
>
> -idesisnery
>
>
>
>> Cheers
>>
>> Remo
>>
>> > -Original Message-----
>> > From: bf-committers-boun...@blender.org [mailto:bf-committers-
>> > boun...@blender.org] On Behalf Of horace grant
>> > Sen
ommitters-
> > boun...@blender.org] On Behalf Of horace grant
> > Sent: Mittwoch, 28. April 2010 4:57
> > To: bf-blender developers
> > Subject: Re: [Bf-committers] "Security" gets in the way
> >
> > On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tol
ilto:bf-committers-
> boun...@blender.org] On Behalf Of horace grant
> Sent: Mittwoch, 28. April 2010 4:57
> To: bf-blender developers
> Subject: Re: [Bf-committers] "Security" gets in the way
>
> On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt
> wrote:
> > hor
On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt
wrote:
> horace grant wrote:
>> no need for lua. python is the much nicer language. :p there is pypy
>> which supports sandboxing and which also gets cpython api compatible
>> at the moment.
>>
>> http://morepypy.blogspot.com/2010/04/using-cpython-
horace grant wrote:
> no need for lua. python is the much nicer language. :p there is pypy
> which supports sandboxing and which also gets cpython api compatible
> at the moment.
>
> http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html
>
> in 2 years or so (once pypy is mo
On Wed, Apr 28, 2010 at 10:35 AM, Remo Pini wrote:
> Hm...
>
> To me - as a person coming from the IT security field - there seems to be an
> interesting conundrum:
>
> At some point in the past, someone made the choice of using Python as the
> pervasive scripting language in Blender. We've all
Daniel Salazar - 3Developer.com wrote:
> So the scenario here as I see it is: people who don't know about this
> leave the loading of scripts off (and are safe from the evil blender
> hackers out there), next people start having the problems related to
> this setting and due to it being unusable in
Hm...
To me - as a person coming from the IT security field - there seems to be an
interesting conundrum:
At some point in the past, someone made the choice of using Python as the
pervasive scripting language in Blender. We've all heard through various emails
on how it is basically NOT possibl
So the scenario here as I see it is: people who don't know about this
leave the loading of scripts off (and are safe from the evil blender
hackers out there), next people start having the problems related to
this setting and due to it being unusable in production they find out
how to disable it eve
added -Y option to enable script execution, this means render nodes
don't need to have .B25.blend's
eg.
./blender.bin -b -Y myblend.blend -a
On Wed, Apr 28, 2010 at 3:00 AM, Daniel Salazar - 3Developer.com
wrote:
> I have a history of lost work and time with this so called security
> features
Matt Ebb wrote:
> Sure, one can say "oh it's your fault for not enabling the options"
> but that brings me back to the original point - regardless of whether
> you want to blame the user or not, the existence of this 'security'
> does cause real practical problems. Especially in cases like I
> desc
For the record, I am in no-way criticising the developers or what they
did in trying to plug the security hole. The issue is that Python has no
concept of (nor do their core development team wish to address) process
security when used as an embedded language. Python is a language
designed to be "ex
On Wed, Apr 28, 2010 at 12:09 PM, Benjamin Tolputt
wrote:
> Matt Ebb wrote:
>> This stuff is unnecessary in a studio environment,
>
> Agreed. The primary target user-base for the security issue are new &
> inexperienced users who *will* download material online and install it
> without thinking ab
Matt Ebb wrote:
> This stuff is unnecessary in a studio environment,
Agreed. The primary target user-base for the security issue are new &
inexperienced users who *will* download material online and install it
without thinking about the consequences because they are simply unaware
of them. Much l
On Wed, Apr 28, 2010 at 11:00 AM, Daniel Salazar - 3Developer.com
wrote:
> In 2.5 since the inclusion of the "trusted source"
> option this has done nothing but cause problems everywhere
As I was mentioning with Daniel on IRC, I completely agree. These
'security' additions have always caused me
I have a history of lost work and time with this so called security
features where blender decides to turn off drivers and ignore script links
and so on and you don't notice it until you have worked on a faulty
rig/scene for a long time or you have rendered some heavy frames and have to
do it all
91 matches
Mail list logo
