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 <rogerwic...@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 >> 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 >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers