Setting aside the bigger issues of security, the 'Trusted' option has some problems. Basically there are 2 booleans. 1) default trust on/off (userpref) 2) current trust state on/off (global)
Only 1 is made clear from the user prefs. Should probably have some option to set autoexec on/off for the session only. Realize this isn't communicated well so I'll try improve when I get some time. On Wed, Mar 24, 2010 at 5:30 PM, Roger Wickes <[email protected]> wrote: > Hey Richard, > > I would only want it on if I was running in a secured environment > where no/few new untrusted blend files are ever downloaded, and the feature > is desired/needed. Otherwise, off. If you want/need the feature on, AND you > are > practicing unsafe downloading, then you need to practice safe downloading > first > before enabling the feature. > > You don't implement security at run-time, it is implemented during > development and installation. We have adequate security now; no further > measures > are needed. As per previous email, I demonstrated that the pipeline is under > adequate control now. If you control the factory and the pipeline that > delivers > the product, product assuranceis guaranteed. > > Just to be exact, as it may be a misconception, but Blender is not run by a > script. > Blender is run by the OS, which loads a blend file, and then loads the script. > I cannot see a situation where a back-end server admin is running > blends/scripts > that have not been tested and verified and under SVN, so auto-run is fine from > a security standpoint, but as I pointed out, bad from a self-documenting, > in-the-clear-what-is-this-command-doing standpoint. > > A script can load another blend file, upon which it loses all state. > I think you can then have that blend file auto-execute (if enabled) > yet another script, but I have not and would not do so from a server > operations standpoint. I would simply have the first one quit, and > then invoke the second one via a second command line. > The server-side RPC Blender implementations that > I have writtenall explicitly load a script; auto-run is off. > >From a late-night debugging-why-the-heck-did-my-run-fail standpoint, > instead you want each unique command in the batch/cmd file > invoked separately, and not have this chain of weak links fail > somewhere in the middle. You want to know exactly which command line > and script failed, as each command is logically separate. > > > If I write a command line that executes a script, i don't need > another option to force execution of the script. I put the command there > in the first place. I told it to execute, by writing the command in the first > place, and by running the batch file...so it should do what I said to. > > To use an analogy, If I put the key in the ignition and turn it, > the car should not popup and ask me if I want to start the car. > > --Roger > > > > > > ________________________________ > From: Richard Olsson <[email protected]> > To: bf-blender developers <[email protected]> > Sent: Wed, March 24, 2010 10:04:24 AM > Subject: Re: [Bf-committers] Blender security paranoia > > 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. :) > > /R > > > 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. >> Cheers, >> Erwin >> >> On Mar 24, 2010, at 6:30, Roger Wickes <[email protected]> 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 >>> auto >>> script >>> execution and open it up. Look at it, see what it does, and execute >>> it >>> 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 >>> to >>> 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. >>> >>> --Roger >>> >>> >>> >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
