One setting only stores the default state for the 'Trusted' button, The other stores if you loaded a file with 'Trusted' enabled or not.
On Wed, Mar 24, 2010 at 5:45 PM, Erwin Coumans <[email protected]> wrote: > This is becoming very confusing. > > Can you explain clearly the difference between > 'current trust state (user pref)' and 'default trust (global)'? > > I expected at least one simple option: > > 1) enable autoexec of scripts > > While the setting defaults to OFF, this option could be switched on/off > in the user prefs, or using a command-line argument. > Thanks, > Erwin > > > > > > > > > On 24 March 2010 09:35, Campbell Barton <[email protected]> wrote: > >> 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 >> > _______________________________________________ > 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
