[Bf-committers] Blender security paranoia
r at richardolsson.se
Wed Mar 24 15:04:24 CET 2010
Just a question,
Why would you want it on? From my understanding of your e-mail, Roger,
you think that having a confirmation popup defeats the purpose of
having automatic script execution. While I do agree that it would no
longer be automatic, I think that the number one use case of auto-exec
is when blender is executed from the command-line, i.e. by a script.
In those situations, a simple command-line option forcing automatic
execution of scripts, overriding the confirmation dialog, would be the
way to go, I think.
Excuse me if I misunderstood. :)
On 24 mar 2010, at 14.46, Erwin Coumans wrote:
>>> leaving auto-execute on.
> You meant switching it on?
> As far as I know, auto-execution of python scripts when loading .blend
> files is turned off by default in SVN trunk.
> And I'm glad it is.
> On Mar 24, 2010, at 6:30, Roger Wickes <rogerwickes at yahoo.com> wrote:
>> So, a little logic to this paranoia, and hopefully a process of
>> elimination. Also,
>> confirmation of what security we do have in place already, to make
>> everyone rest easier.
>> I agree that while however slight, the chance of having your PC
>> wiped by a malware script
>> is troubling because there is no recourse against the evildoer. That
>> there is money made
>> from it is no doubt. I discovered that I had malware sending my hard
>> drive contents to Russia.
>> We can all agree that having a pop-up stop and force you to
>> confirm automatic script
>> executionisn't automatic script execution
>> and therefore defeats the purpose of the option in the first place:)
>> So if your all your scripts, like all programs installed on your PC,
>> are all from trusted sources,
>> you can enable auto-execute. Just like when I start OpenOffice, my
>> OS does not popup and
>> ask me if I want to execute OpenOffice. That would be just as
>> painful as the current
>> set of delete confirmation popups in Vista.
>> The only way for a script to become part of the blender install is
>> for a trusted dev
>> to accept the patch. There has never been a case where malware patch
>> has been
>> accepted, and highly unlikely to ever be. Commit rights are only
>> granted to trusted devs.
>> That leaves the possibility of someone hacking SVN, someone with
>> commit rights, or
>> somehow hacking into the blender.org or graphicall.org servers and
>> inserting a bad
>> script (or compiled C code) without detection. That is a server
>> security issue, not a sandbox problem.
>> There is both physical access and username/password security
>> protecting them.
>> So that leaves someone posting a script in like BA that no one knows
>> and it may
>> or may not do something bad. In that case, you are getting a program
>> from an untrusted source. You can be a trusting person and just run
>> it, or,
>> since you got a new blend file from an untrusted source, you disable
>> execution and open it up. Look at it, see what it does, and execute
>> if you like.
>> Just as likely is someone building an evil Blender and posting the
>> build somewhere for people
>> to download. That is the general problem with software available for
>> the internet,
>> and the only way to stop that is user education, unexpired
>> certificates, and OS protection.
>> If it is malware, community response will be immediate and vengeful,
>> for either Blender exe
>> or scripts. AFAIK scripts cannot be signed; they are text files.
>> Perhaps pyc files can be, but
>> distributing source is the practice.
>> That really leaves only one remaining possibility. I think you guys
>> are worried about the noob
>> that is one of the very first to find the malware, and then proceeds
>> run un-human-readable stuff (compiled code, pyc files) on their PC,
>> or blindly runs source py files and does not read them or cannot
>> understand them,
>> or downloads and opens a blend file, leaving auto-execute on.
>> That is the same issue as downloading any kind of
>> program and running it; it is impossible to protect a user from
>> their own stupidity.
>> Therefore, there is nothing further that can reasonably be done, and
>> no additional processes
>> or procedures need to be implemented.
>> Therefore, the safest route is to ship Blender with auto-execute
>> turned off, and let the user decide
>> to turn it on, or instead, run scripts after reviewing them. Either
>> way, the process and existing
>> security measures guard the pipeline and the contents of the pipe.
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers