Despite getting several black eyes over the “Safe” file opening preference before (with Dashboard Widgets and protocol trickery), this option is still a mine field. This time, Safari will execute files contained within a Zip archive without properly checking if the contents are safe.
In fact, one can rename a shell script to a picture extension to wreak all kinds of havoc. Until Apple releases an official fix, you have three options. First, don’t use Safari (a fairly silly solution, reminiscent of cutting off one’s nose to spite their face), opting instead for Camino, Opera, or Firefox. Second, disable “Open ‘safe’ files after downloading” in Safari’s preference. Finally, use the updated Paranoid Android. Unsanity has been all over this kind of stuff, and even has an alternate piece of software to do the same thing.
At any rate, I’m not turning this preference back on for a long time, despite any assurances by Apple.
Update: Rosyna of Unsanity has further fleshed out his blog entry on the problem. The problem is rooted in what he calls strong bindings and the fact that an alternatively chosen opening application for a document is not checked when making the “safe”. Bad. The use of strong bindings can also be used to trick a user in environments outside Safari and Mail.app, but the exploit basically degenerates to making a file look like something other than it really is (like the Word 2004 trojan floating around on P2P networks). It’s slightly more sophisticated but it still requires social engineering to properly work.
You say "...Safari will execute files contained within a Zip archive without properly checking if the contents are safe."
That's not true at all. For one thing, Safari isn't doing the checking at all, it's the Mac OS that's checking. Scripts are considered "unsafe" files according to the OS, so it will not open them after downloading with Safari.
But what tells the OS if it's a script? Why, it's none other than the shebang line! Without this, that script becomes just another file to the OS and unless it meets certain other criteria stored in the Mac, it's considered safe.
Creating a script without the shebang line, adding an extension like .jpg and then creating a Zip archive is not going to cause it to execute in Terminal. Same with Mail, or any other application.
So you don't understand what's really going on or how this vulnerability (which has existed for years) actually works. You're blowing it out of proportion due to pure ignorance.
Ok, so I didn't mention the metadata aspect of the exploit. The fact remains, Safari is launching the file. (Note that other browsers do not have this issue.)
Whether Safari or the Mac OS is technically the one making the safe determination is neither here nor there. The determination is wrong and Safari is using it to make the decision to launch or not.
The behavior is wrong and is a serious problem.
Gruber's got a good explanation of what the security hole involves over at Daring Fireball. Unchecking safe seems to be the way to go for now, though I really like his suggestion that Apple implement some sort of visual cue around a file's icon when the metdata and file type suffix don't match up.