On Wed, Jun 12, 2013 at 2:32 AM, Campbell Barton ideasma...@gmail.com wrote:
On Tue, Jun 11, 2013 at 8:49 PM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
On Tue, Jun 11, 2013 at 8:35 AM, Campbell Barton ideasma...@gmail.com
wrote:
- Asking to reload a file is OK, but what if you
How about a script that automatically checks each script in the .blend when
it opens, before auto-running scripts... but it ONLY pops up an alert if it
detects suspicious code, any specific functions that wouldn't normally be
needed in a .blend file or stand a good chance of messing things up.
Right now the information about this file contains autorun scripts
gets displayed right after the script is loaded, but goes away as
soon as i have decided to either run the sripts or not run them.
I believe it is much more indicative if this information would
be displayed permanently, like so
A suggestion that hasn't be done before here (but it's related to the post
I'm replying to):
Hash all the potentially dangerous data (scripts, driver expressions,
anything that has python code) and store those hashes when the user chooses
to trust the .blend file. If someone heavily modifies
Update on whats going on:
- Default has been changed not to auto-run scripts, with option to
reload a blend if it attempts to run a script.
looks like this: http://www.graphicall.org/ftp/ideasman42/trust_header.png
- Since this is a user preference, Users with current preferences
saved won't
It's perhaps somewhat irrelevant at this point in time (since we've
now already got a solution in progress), but for posterity, I thought
I'd just mention some thoughts I had about this situation yesterday.
As Miika says, it's clear that trying to do runtime protection (i.e.
sandboxing) is
On Tue, Jun 11, 2013 at 8:49 PM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Hi,
On Tue, Jun 11, 2013 at 8:35 AM, Campbell Barton ideasma...@gmail.com wrote:
- Asking to reload a file is OK, but what if you haven't saved the
file? (eg, you load a new file and append an object with a
Sure, not everyone's a programmer that can inspect the scripts, but at some
point I feel the responsibility lies with the users and with the sites
offering the .blends to inform them of potential dangers, and not so much
with the BF trying to create a super-safe environment. Super-safe in
On Sun, Jun 9, 2013 at 5:37 PM, Knapp magick.c...@gmail.com wrote:
Sure, not everyone's a programmer that can inspect the scripts, but at some
point I feel the responsibility lies with the users and with the sites
offering the .blends to inform them of potential dangers, and not so much
IMHO the situation is clear: It's practically impossible to detect
malicious scripts or make script execution fully safe. Implementing a
safe scripting environment could be a nice long term target, but the
main issue has to be addressed sooner. Therefore only solution is to
inform users about
Maybe you can put security aside for a moment and first
look at this topic from the information perspective:
Wouldn't it be nice to get informed whenever a .blend file
contains scripts ? That could be simply a python icon next
to the blender icon in the main menu header for example.
This could
Hi Erwin,
Put yourself in the position of someone who purchases the famous CGcookie
animation training DVD. On loading the first tutorial file, Blender then throws
a popup:
This .blend file contains autorun scripts, do you want to run it?
I consider such requests totally void of any meaning,
Hi Campbell,
Thanks for clarifying.
Limiting module access is just really hard to do... snip
unless you remove the functionality altogether.
Just in theory then: so we can make a (static linked) Python interpreter
without any modules, and not allowing to load any other module or C compliled
Ton,
I disagree with you on this point.
If I know the origin of .blend file is trusted, I will choose Yes to auto-run
scripts, obviously.
I want to have this missing choice. To me that is exactly the same as
downloading and executing files from a web browser: you get to choose.
Why not add
with an additional layer of control and security.
Just my two cents,
Patrick
From: t...@blender.org
Date: Sat, 8 Jun 2013 13:23:26 +0200
To: bf-committers@blender.org
Subject: Re: [Bf-committers] Please turn off Auto Run Python Scripts by
default
Hi Erwin,
Put yourself in the position
Something quite important has to happen in order to turn a one-to-one
attack into a virus-like problem.
As patient zero I get the first bad blend. It can't immediately do
something bad to me or that is the end of the infection as I will not be
able to infect anyone else. Instead it needs to make
On Sat, Jun 8, 2013 at 10:02 PM, Ton Roosendaal t...@blender.org wrote:
Hi Campbell,
Thanks for clarifying.
I should have been a more clear in fact, (there are probably more
workaround) but basic issues with restricting module access are...
- modules are already loaded into python, so there
On Sat, Jun 8, 2013 at 11:55 AM, Harley Acheson harley.ache...@gmail.comwrote:
Something quite important has to happen in order to turn a one-to-one
attack into a virus-like problem.
As patient zero I get the first bad blend. It can't immediately do
something bad to me or that is the end of
...@blender.org
Date: Sat, 8 Jun 2013 13:23:26 +0200
To: bf-committers@blender.org
Subject: Re: [Bf-committers] Please turn off Auto Run Python Scripts by
default
Hi Erwin,
Put yourself in the position of someone who purchases the famous CGcookie
animation training DVD. On loading
Hi Campbell,
I don't know enough about Python internals, so I depend on someone to help
designing a sane way to handle security risks here. There must be ways we can
help users?
Look for example at the standard UI scripts. Apart from 1 case, there's no
import os anywhere. Same goes for
Hi,
Besides making Blender safer I think it is also important to make users
more self aware of risks.
Two humble propositions:
- first run splash screen with something like: Thank you for choosing
Blender. Beware of evil .blend files from unauthorised sources..
- small info beware of .blend
Hi,
this is a bad idea (especially the first one).
Adobe Reader also doesn't tell me on first start Thanks for using Adobe
Reader, be aware of evil .pdfs.
I bet inexperienced people will get afraid reading that and come to the
conclusion, that this blend format is very insecure and shouldn't be
On 06/07/2013 10:21 AM, Ton Roosendaal wrote:
Hi Campbell,
I don't know enough about Python internals, so I depend on someone to help
designing a sane way to handle security risks here. There must be ways we can
help users?
Look for example at the standard UI scripts. Apart from 1 case,
Hi all Pythoneers,
Scripters are important for Blender, but just like the C developers they have a
responsibility for users out there. A good proposal for security has to come
from you as experts first.
If this discussion just leads to marking every idea as impossible (Python is
insecure by
Hi Ton,
Comments inline ;)
Am 07.06.2013 um 13:12 schrieb Ton Roosendaal t...@blender.org:
Hi all Pythoneers,
Scripters are important for Blender, but just like the C developers they have
a responsibility for users out there. A good proposal for security has to
come from you as experts
If you want security by default then my suggestion is to just disable
scripts by default on load. If the .blend file contains a script the
info header can show a warning and button to reload the .blend file
with scripts enabled.
Realistically I think Python and the Blender Python API are just
On 07.06.2013 15:15, Brecht Van Lommel wrote:
If you want security by default then my suggestion is to just disable
scripts by default on load. If the .blend file contains a script the
info header can show a warning and button to reload the .blend file
with scripts enabled.
As a user and
On Fri, Jun 7, 2013 at 4:42 PM, Ton Roosendaal t...@blender.org wrote:
Hi all Pythoneers,
Scripters are important for Blender, but just like the C developers they
have a responsibility for users out there. A good proposal for security has
to come from you as experts first.
Why not have a
Gaia had a very good suggestion that is overlooked, so I repeat his email:
Currently we only have 2 options:
- trust everybody (default)
- trust nobody (use the -Y commandline parameter.
We need the third option, selectively enable scripts, at loading time.
- i care: ask me case by case
Why
I still maintain that this an attempt to deal with what is only a
(hypothetical) one-to-one attack. This is not like a Word macro or
virus-infected exe which results in a one-many-many attack.
One-to-one attacks aren't worth dealing with since the damage doesn't
spread outward from the attacked.
Hi,
I don't think I understand what you're saying here.
Sorry wasn't clear, I referred to auto-run of scripts. If a user installs an
add-on, then it's at least a concious decision to use it. The source of add-on
is known, and a user can decide to stick to official released ones. That's
Hi Shrinidhi,
Why not have a script that ships with blender, which can be run
individually, which checks the blender file for scripts and informs the
user if it is malicious or safe ?
That's interesting to check, but I don't like to make users responsible for
checking each .blend they want
I just want Blender to ask me at loading time, if I want to run scripts or
not. Obviously option should be a user preference.
At loading time you can then reply:
1) run script this time
2) don't run scripts this time
3) always run scripts and don't nag/ask me ever again
4) never run scripts and
Hi,
Making autorun default off (and optional) is really a good start. But it's not
enough. Especially requesters won't work well. Nearly every person who gets the
menu Do you want to run this script wouldn't know what to anwser.
It's like a click on I agreed with the license. Only lawyers are
Nearly every person who gets the menu Do you want to run this script
wouldn't know what to anwser.
I think you under-estimate Blender users.
People are familiar with such a question, for example when using a web
browser. I think it is good to give the user control.
On 7 June 2013 09:26, Ton
On Fri, Jun 7, 2013 at 7:21 PM, Ton Roosendaal t...@blender.org wrote:
Hi Campbell,
I don't know enough about Python internals, so I depend on someone to help
designing a sane way to handle security risks here. There must be ways we can
help users?
So far I can only see the way to help
That's interesting to check, but I don't like to make users responsible
for checking each .blend they want to load. My preference is a way that's
relatively safe and works out of the box for everyone (except system
administrators :).
what if we can make it a feature of blender itself and on
On Fri, Jun 7, 2013 at 2:48 AM, Thomas Dinges blen...@dingto.org wrote:
Hi,
this is a bad idea (especially the first one).
Adobe Reader also doesn't tell me on first start Thanks for using Adobe
Reader, be aware of evil .pdfs.
I bet inexperienced people will get afraid reading that and come
This is the best I think one can hope for given the limitations of CPython and,
honestly, all I really desire from Blender in this regard. Like Microsoft's
infamous macros, because of the way in which the language/platform is put
together (Python, not Blender) there is not levels of security.
Hi,
I think you give up too easily here. :) For example, we could also make a
bpy.os module, and mark scripts that use this as 'trusted'. Scripts using the
os.module itself then require a user to explicitly run it, or being embedded in
a file marked trusted (own files etc).
This is not to
Hi Jace,
I am not talking about your use case. You should be able to code whatever you
like.
However, when it comes to the binaries and software we release for everyone, I
expect developers to accept some responsibilities here.
We try to keep up with a high standard for C/C++ developers for
On Tue, Jun 4, 2013 at 11:40 PM, Campbell Barton ideasma...@gmail.com wrote:
To avoid further threads on this topic added a section to our developer FAQ.
http://wiki.blender.org/index.php/Dev:Doc/FAQ#How_Does_Blender_Deal_with_Security.3F
Thank you for taking an action. The section you added
Hi,
The section you added gives a clear
explanation of the stance of developers that they accept the risk of
opening an untrusted blend file.
That's not really true, it only explains how things work currently.
I still aim for finding decent ways to better handle this risk.
-Ton-
The section you added gives a clear
explanation of the stance of developers that they accept the risk of
opening an untrusted blend file.
That's not really true, it only explains how things work currently.
I still aim for finding decent ways to better handle this risk.
My apologies. I
On Thu, Jun 6, 2013 at 6:47 PM, Ton Roosendaal t...@blender.org wrote:
Hi,
I think you give up too easily here. :) For example, we could also make a
bpy.os module, and mark scripts that use this as 'trusted'. Scripts using the
os.module itself then require a user to explicitly run it, or
On Thu, Jun 6, 2013 at 11:13 AM, Campbell Barton ideasma...@gmail.comwrote:
On Thu, Jun 6, 2013 at 6:47 PM, Ton Roosendaal t...@blender.org wrote:
I think you give up too easily here. :) For example, we could also make
a bpy.os module, and mark scripts that use this as 'trusted'. Scripts
On 07/06/2013, at 4:13 AM, Campbell Barton wrote:
On Thu, Jun 6, 2013 at 6:47 PM, Ton Roosendaal t...@blender.org wrote:
Hi,
I think you give up too easily here. :) For example, we could also make a
bpy.os module, and mark scripts that use this as 'trusted'. Scripts using
the os.module
On Fri, Jun 7, 2013 at 8:09 AM, Chad Fraleigh ch...@triularity.org wrote:
On Thu, Jun 6, 2013 at 11:13 AM, Campbell Barton ideasma...@gmail.comwrote:
On Thu, Jun 6, 2013 at 6:47 PM, Ton Roosendaal t...@blender.org wrote:
I think you give up too easily here. :) For example, we could also
As a normal hobby users, the biggest risk that I see is downloading a
blend from the net and opening it. This is not something we are likely
to give up. So, warning or not, what good is it? I need some way to
know if the file is good or bad. I don't see an answer. I would say a
good third of the
On Wed, Jun 5, 2013 at 8:03 AM, Knapp magick.c...@gmail.com wrote:
As a normal hobby users, the biggest risk that I see is downloading a
blend from the net and opening it. This is not something we are likely
to give up. So, warning or not, what good is it? I need some way to
know if the file
On Wed, Jun 5, 2013 at 4:21 PM, Knapp magick.c...@gmail.com wrote:
On Wed, Jun 5, 2013 at 8:03 AM, Knapp magick.c...@gmail.com wrote:
As a normal hobby users, the biggest risk that I see is downloading a
blend from the net and opening it. This is not something we are likely
to give up. So,
Hi,
I've checked some history of past discussions (including sandboxing Python) and
to me it seems we still accept too much risk here. As a team (and for me as
Blender Foundation chairman) I feel it's a big responsibility to not waive away
so easily.
More over - it's a disaster waiting to be
Hi,
Here's just some ideas to investigate:
1) Better location for temp saves
- remove /tmp/ usage from our default, and move it to sane a path inside user
space. We can call this sandbox or so, which (on first use) could also be
confirmed by users to be used as such.
- sandbox paths could
On Wed, 2013-06-05 at 14:35 +0200, Ton Roosendaal wrote:
Hi,
Here's just some ideas to investigate:
1) Better location for temp saves
1) is actually really nice, /tmp has issues on some systems still and we
often move the default to inside the home dir. esp. some systems don't
keep /tmp
Hi,
Things
that we need to do are in the file manipulation range, such as moving or
renaming large numbers of files
Well, that you can do outside Blender via regular Python too?
Further - if we can make file manipulations in the UI work sane/safe (and
usable still), the hacked os module
In reply to Ton Roosendaal (t...@blender.org):
From: Ton Roosendaal t...@blender.org
Date: Wed, 5 Jun 2013 14:35:16 +0200
To: bf-blender developers bf-committers@blender.org
X-Mailer: Apple Mail (2.1283)
Subject: Re: [Bf-committers] Please turn off Auto Run Python Scripts by
default
Reply
Ton Roosendaal t...@blender.org wrote:
Hi,
Things
that we need to do are in the file manipulation range, such as moving or
renaming large numbers of files
Well, that you can do outside Blender via regular Python too?
Further - if we can make file manipulations in the UI work
Disabling os module might cause a lot of problems. Pipeline and other batch
scripts rely on it a lot.
We also use a lot of absolute path in our pipeline scripts since we move a
lot of files across directories for version control , publishing to the
next stage , import directories of the stages ,
Hi,
I am not proposing to make advanced system adminstration entirely impossible.
It's just not a sane default to release, nor to give to everyone in a studio.
The challenge is to find out a good, sane and usable way to configure Blender
securely.
It could work all fine for people in studios
Hacked os module isn't really an option, Python uses this for its
internal operations all over the place - a lot of python modules are
written in Python so these would break.
In python3.3 module dir...
find -name *.py | xargs grep \bos\. | wc -l
-- 7833
Attempting to let Python do its own thing
Another +1 for not changing the OS module, or anything else for that
matter. I use lots of python system-related modules, including OS, in my
import/export/interop pipeline. If it is broken I will most likely not be
using blender anymore (seriously).
Additionally, I don't believe security in
On Thu, Jun 6, 2013 at 5:21 AM, Jace Priester
jacepries...@threespaceimaging.com wrote:
Another +1 for not changing the OS module, or anything else for that
matter. I use lots of python system-related modules, including OS, in my
import/export/interop pipeline. If it is broken I will most
There was a decision to turn autorun on even if it causes potential
security issues, what it comes down to is that we can't really secure
python scripts, but they are critical for many artists worksflows.
For a long discussion on the topic see here:
Also, good to know that there is a Trusted source checkbox in the file
browser while opening a file, which can be disabled for a particular file
that you may not trust.. that will prevent autorun scripts.
___
Bf-committers mailing list
there is a command line option (-Y )if you want to turn it off . in linux u
can alias blender with -Y option .in windows u can edit the properties of
the shortcut to start blender with the -Y option . turning it off will
cause hell to break out in a studio that's using blender . :)
On Tue, Jun
Thank you for the reply, and especially for the pointer to the
previous discussion in April and May 2010. I was not aware of it.
I think I took a look at all the messages in that thread in the
archive. Now I understand it is unacceptable to some people to
disable autoruns by default. So I will
In User Preferences - Files i found the option Auto Run Python Scripts
I have disabled this option in my blender setup. However i also like your
idea to have the additional option:
- Ask user on load (when Autorun is disabled in user preferences)
Furthermore it would be nice if i where able to
Dear Thomas,
As I wrote in the first email, I know there are options to change the
behavior, and I am questioning the *default* behavior.
I agree a confirmation popup is not nice, but I am suggesting the
confirmation as a compromise to make Blender secure by default without
causing data loss to
There's a compile time flag that does this if you're into that sort of
thing -- WITH_PYTHON_SECURITY I believe it is -- that the linux distros use
it for their packaged blender builds
Well, except fedora who uses WITH_PYTHON_SAFETY which still auto-runs
scripts and gives you much slower python
Here's another discussion where the popup idea comes up:
http://lists.blender.org/pipermail/bf-committers/2010-March/026573.html
It's a tradeoff, do we really want to degrade usability for this? The
decision at the time was that no, we do not. Also note that even
disabling scripts does not make
On Tue, Jun 4, 2013 at 8:05 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Here's another discussion where the popup idea comes up:
http://lists.blender.org/pipermail/bf-committers/2010-March/026573.html
It's a tradeoff, do we really want to degrade usability for this?
I don't
Hi,
I think I would have to agree with David's stance here.
A studio would most certainly track changes to blenders behavior, at
least more likely so compared to a new user, and also know of this
feature very well. I honestly can't see a safe default of disabled py
scripts affecting a
...@blender.org] Im Auftrag von David Jeske
Gesendet: Dienstag, 4. Juni 2013 19:59
An: bf-blender developers
Betreff: Re: [Bf-committers] Please turn off Auto Run Python Scripts by
default
On Tue, Jun 4, 2013 at 8:05 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Here's another discussion where
about it.
/Jürgen
-Ursprüngliche Nachricht-
Von: bf-committers-boun...@blender.org
[mailto:bf-committers-boun...@blender.org] Im Auftrag von Thomas Dinges
Gesendet: Dienstag, 4. Juni 2013 20:16
An: bf-blender developers
Betreff: Re: [Bf-committers] Please turn off Auto Run Python Scripts
That it is possible to create something bad withing a Blend file is not
enough, on its own, for this to be a threat worth considering. Trying to
propagate a virus or other nasty behavior via Blend files would be a silly
waste of time for the perpetrator.
This is because it is not a method that
On Wed, Jun 5, 2013 at 3:58 AM, David Jeske dav...@gmail.com wrote:
On Tue, Jun 4, 2013 at 8:05 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Here's another discussion where the popup idea comes up:
http://lists.blender.org/pipermail/bf-committers/2010-March/026573.html
It's a
...@blender.org] Im Auftrag von Thomas Dinges
Gesendet: Dienstag, 4. Juni 2013 20:16
An: bf-blender developers
Betreff: Re: [Bf-committers] Please turn off Auto Run Python Scripts by
default
I may see this too simple, but you also don't run any .exe file you get your
hands on, on your computer
developers
Betreff: Re: [Bf-committers] Please turn off Auto Run Python Scripts by
default
I may see this too simple, but you also don't run any .exe file you get your
hands on, on your computer.
In the end it all comes down to Do I trust the source, yes or no. ;)
Come on, how often did you got
On Tue, Jun 4, 2013 at 7:58 PM, David Jeske dav...@gmail.com wrote:
The decision at the time was that no, we do not. Also note that even
disabling scripts does not make Blender secure, there's dozens of
other ways to create malicious .blend files.
What are the other dozen ways blender could
On Wed, Jun 5, 2013 at 5:38 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
On Tue, Jun 4, 2013 at 7:58 PM, David Jeske dav...@gmail.com wrote:
The decision at the time was that no, we do not. Also note that even
disabling scripts does not make Blender secure, there's dozens of
other
Thank you for the list of potential risks. I cannot judge how
difficult it is to solve all of them and make it safe for a user to
open an untrusted blend file, but it seems it is much harder than I
expected.
If it is too hard, do you think it is easier to better communicate to
users that opening
isnt using a computer itself a risk ?! . why not just disable the net and
other out worldly connections to the comp . ? y do we want to use a hard
disk? ..isnt it possible that some app will always overwrite our data? we
might even format it by mistake .
i would prefer usability rather than
Not sure this discussion is really going anywhere now - there are
valid arguments for/against this being on by default, but this was
decided back in 2010 and I don't see that decision changing.
To avoid further threads on this topic added a section to our developer FAQ.
This issue would be less problematic if new versions of blender would read
preferences set from older versions. Currently in my experience all
preferences have to be re-set after each new version download. Which means
if you turn off auto load scripts it only stays off until the next
download.
On
On Wed, Jun 5, 2013 at 3:15 PM, David Jeske dav...@gmail.com wrote:
This issue would be less problematic if new versions of blender would read
preferences set from older versions. Currently in my experience all
preferences have to be re-set after each new version download. Which means
if you
85 matches
Mail list logo
