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
