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
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
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 letter...@gmail.com wrote:
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
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,
I wonder how Sketchup deals with this issue with their embedded ruby...
On 4/30/10, Benjamin Tolputt btolp...@internode.on.net wrote:
Campbell Barton wrote:
Best bring this up next meeting and come to some consensus. I wasn't
in IRC for the decision either :)
Interesting to note :)
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,
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,
Sorry if this discussion is considered closed, but I wanted to read
everything before chiming in.
On Wed, Apr 28, 2010 at 9:06 AM, Benjamin Tolputt btolp...@internode.on.net
wrote:
However, the sand-boxing as presented in PyPy is very crude and will
do nothing to fix the issues with Python in
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
Jason Wilkins wrote:
I think this is incorrect. The way PyPy is implemented presents a possible
solution. Depending on the maturity of PyPy this may be ways off, so I'm
just throwing this out to be considered.
PyPy is a meta-circular interpreter, what that boils down to is the fact
that
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
On Fri, Apr 30, 2010 at 7:39 PM, Benjamin Tolputt btolp...@internode.on.net
wrote:
I believe that resistance to this idea is based around the very valid
question of Who is going to maintain this subset interpreter?.
I understand this and is why I need to look and see just how simple it is to
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
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
___
*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
--- 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
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
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
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
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
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,
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
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
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
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,
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
...@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
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
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
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
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
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
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
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
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
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
--- 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
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
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
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
On Wed, Apr 28, 2010 at 4:06 PM, Benjamin Tolputt
btolp...@internode.on.net 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.
] 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
btolp...@internode.on.net wrote:
horace grant wrote:
no need for lua. python is the much nicer
: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
btolp...@internode.on.net wrote:
horace grant wrote:
no need for lua. python is the much nicer language. :p there is
pypy
which supports sandboxing
. 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
btolp...@internode.on.net wrote:
horace grant wrote:
no need for lua. python is the much nicer language. :p there is
pypy
which supports
-Original Message-
From: bf-committers-boun...@blender.org [mailto: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
On Wed, Apr 28, 2010 at 10:52 PM, Makslane Rodrigues
maksl...@game-editor.com 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
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
___
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
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 Maya
--- On Wed, 4/28/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: Wednesday, April 28, 2010, 8:31 PM
Charles Wardlaw
Wireless BlackBerry
-Original Message-
From: Benjamin Tolputt btolp...@internode.on.net
Date: Thu, 29 Apr 2010 11:45:20
To: Benjamin Tolputtbtolp...@internode.on.net; bf-blender
developersbf-committers@blender.org
Subject: Re: [Bf-committers] Security gets in the way
Sorry
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 the
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
On Wed, Apr 28, 2010 at 12:09 PM, Benjamin Tolputt
btolp...@internode.on.net 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
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
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
described
58 matches
Mail list logo
