And after the longest beta test in the history of the world, too! I won't go into the features here since they're a click away, but I should mention that most of them are under-the-hood changes, safety for the future type things.
But you can tweak colors individually in guiTweak now, which means that if there's a theme you almost like, you can probably fix it yourself in just a couple of minutes.
The download tab also lights up now when there's a new download available. I hope more themers will submit their downloads!
Intel compatibility is next on the plate! In the meantime, grab ShapeShifter 2.3!
Looks like it's OS X security vulnerability season! I've updated Paranoid Android to handle the class of exploit described here.
Basically, what's going on with that type of exploit is that somebody created a shell script, gave it a filename extension and type/creator to make it look like a Quicktime movie, but used the Finder's Get Info command to specify that it should be opened in Terminal.
That's rather nasty, but it also turns out that if you make the shell script slightly non-standard (no details here, check the above Secunia link), it will auto-execute if you download it in Safari and you've got the open safe files preference turned on. Kinda nasty just turned into very nasty.
Rosyna has a fix for the Safari thing here, but it seems that there might be other vectors besides Safari, so I figured it was time to dust off Paranoid Android.
So, without further ado, Paranoid Android 1.3 adds a new checkbox marked "Watch non-default application launches". If you install PA and then log out and in, you'll be protected from any application trying to launch any file using an application other than the default.
Now, I personally won't be using this - I'll wait for a fix from Apple. But, if you're paranoid, try the Android.
Download Paranoid Android 1.3
Or, for the uber-paranoid or terminally curious, download the source code.
There is news on the Internets about a recent security exploit in Safari. It's actually a security issue with LaunchServices, so to speak. It has nothing to do with Safari, WebKit, or Mail.app at all.
The problem is a "feature" of LaunchServices. The specific feature with the "problem" is the document binding part of LaunchServices. The binding controls what applications open which documents. There are basically three kinds of bindings.
One, the default binding. These are controlled by the Uniform Type Identifiers, file type, creator code, and (ugh) extension of the file. LS will look into its fancy database and see which of which applications claim these types. LS had a security bug with this method of matching before. The types of files an application would handle would be registered if you even "looked" at the parent folder of an application in the Finder. Then if a document was opened, it would run the application. That was bad, that was publicized, that was quickly fixed by Apple in a manner that made more problems for developers as some API calls that used to work were now extremely iffy. That situation was mostly corrected in Mac OS X 10.4. These bindings are stored as part of the application's that define them Info.plist file. The actual database is stored at /Library/Caches/com.apple.LaunchServices.*.
Two, weak binding. This is the binding that occurs when you get info on, say, a JPEG image in the Finder, choose a new application from the "Open with:" popup, click on the "Change All…" button, stare confusingly at the buggy dialog (the image was a GraphicConverter document, NOT a Preview.app document!), and finally click "Change All". I am not aware of any exploits with these types of bindings. These bindings are stored per user and are located at ~/Library/Preferences/com.apple.LaunchServices.plist. Use the defaults command line utility included with OS X or the Property List Editor included with the Developer Tools (which are free). Weak bindings override the default bindings.
Three, strong binding. Strong bindings are the ones that are causing this security issue. They are created if you do not click the "Change All…" button in the Get Info window in the Finder. This setting is completely per document but not per user or per machine and as such, setting this requires you have write access to the resource fork. If you do not have write access, you'll be asked if you want to do a weak binding instead. If you do have write access, it will create two items in the resource fork. One, an 'icns' (Icon Suite) resource with the id of -16455 entitled "Binding Override". Two, it creates a resource of 'usro' (User Override) with an id of 0. I cannot be sure what the 'usro' resource contains, it may just be a path that as I can clearly see the path to the application. And the resource must be 1028 bytes in size... so much for long paths. Paths are bad and should never be used. Ever. Strong bindings are the law of the land. They override all other kinds of bindings. This is a massively massive problem.
The Problems at Hand
The icon setting itself is a problem as it makes it clear that LaunchServices/IconServices does not get the correct icon when dealing with strong bindings. It has to fake it. This is why the JPEG example exploit has a JPEG icon instead of a Terminal icon. The custom icon was removed, one was not added. This may have been done as a lazy way to fix the large speed hit that could be incurred when opening every file's resource fork and seeing if a 'usro' resource exists, seeing if the stored path exists, and then finding the correct icon for that application. Ugh, very painful indeed. Right now it sees if the file has a "Custom Icon" catalog info finder flag set, and then opens the resource fork. There is no "Has Custom Binding" Finder flag, although I don't see why they couldn't use "Printer Driver is MF Compatible" (kIsOnDesk, I guess). Alternatively, Apple could have set an extended attribute on the file that says the file has a strong binding. This would have fixed both the icon issue and potentially 'usro' issue.
The issue with the 'usro' resource is that it travels along with the file, and it isn't user or machine specific. It also isn't queried when determining the "safety" of a document. So when you download said exploit, Safari kindly decompresses the archive, and then asks LaunchSerices very politely if the file is safe or not. LaunchServices shows Safari the middle finder, checks the dictionary LS loaded from the list at /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/System (or the list at /Library/Preferences/com.apple.DownloadAssessment.plist which can be created if you want to add safe types), finds the file type from the metadata in the file (excluding strong bindings), and then gives it a "risk category". Safari uses this information either to autolaunch a "safe" file, to show the annoying executable warning, or to decompress the archive. If the file is safe and not an archive, Safari will use (eventually) LSOpenFSRef(), which then shoves the finger LS just showed Safari into one of Safari's orifices and opens the application according to the strong binding, completely "bypassing" the security that Safari was trying to enforce. Mail.app does not even attempt to assess the security of a file, it just sees whether the mime type of a file begins with video/ or image/.
My Fix
My simple fix is to patch the function LSCopyDownloadAssessmentDictionary, get what the risk assessment would have been and if it is categorized as safe, I see if the file has a strong binding. If it has a strong binding, I say, "No, you didn't!" and remove the binding. This allows the risk assessment to be correct. If removing the strong binding fails (such as a lack of write permission), then USEF (the "me" in all of this) increases the risk category and marks it as unsafe since LS lied to it. LS is a lying liar and a doo-doo head!
I had thought about removing the bindings for every file unarchived from a file via OS X's built in decompressing services, but then thought that was overkill.
The Fix Apple Should Implement
The big thing is that strong bindings should not transfer between computers!!111oneone!!!eleven! The data stored in the 'usro' resource should be machine dependent (have a non-reversable marker like the MAC address) and ignored if it is opened on another machine. But this could still be used to exploit an admin account on the same machine. In this way, I'd recommend strong bindings either become permanent entries in the per user LaunchServices database or become per user via the metadata method I listed above. Also, LaunchServices/IconServices should get the real icon from the application the file is strongly bound to, not just set some silly custom icon that's easily removed and not dependent on the application at all.
The problem with everyone saying, "just turn off open safe downloads" is that it isn't just Safari with the problem. There's actually scripts out there to turn this off... And by turning this off, you're sacrificing convenience for the sake of a little more security and it'll eventually get to a point that you have so many dialogs you completely ignore what they say (*cough* every new version of Windows *cough*). If you expand the archive yourself, you're still going to have the problem unless you install Jason's "fix" that will ask you whenever you open a document with a strong binding. It'll still be a document with a strong binding.
Actually, now that I've spent the last 3 hours trying to find a way to fix it in Mail.app and have that fix work in Safari, I've realized it cannot easily be done at the head end of the file (when you acquire the file). And if Safe downloads if off, then my patch won't ever run since it is never unzipped.
Jason's "fix" (I say fix in quotes as it is a workaround, just like USEF) tackles the tail end of the problem. It doesn't do anything with the file until it is opened. Although his code is ugly as all sin, it hits 100% of the cases whereas USEF his maybe <1%. But his requires user interaction to continue.
Download UTISafariExploitFix (USEF).
See a happy fun completely benign version of the exploit.
Another less fun version that shows arbitrary applications can be launched. Benign, of course. This is NOT zip compressed archive.
Get Jason's "fix" (sadly recommended)
The source code is included with the USEF download. Including the source to what I just wasted a large amount of time on. Oh well, I did learn stuff. To compile the source code you need the APE SDK and a Spatula. To use the USEF.ape you'll need to download Application Enhancer then put the USEF.ape in either /Library/Application Enhancers/ or in ~/Library/Application Enhancers/, creating them if they do not exist.
Dear fellow Indieware Developers. Never, ever, ever, offer lifetime free upgrades to your product.
It may sound like a cool PR idea at first, and some people actually dig it. But stop right there for a moment, and think about it from your perspective. You do plan on working on that software further, right? And you do plan improving it in the future?
I presume your answer is "yes" to both of these questions. If not, stop reading now - you are not an indieware developer. Otherwise, how are you going to do that in the future? Sure, from the user's perspective, free stuff is always good. But from your perspective, imagine your product stays in the market for several years. How are you going to feed yourself to get these improvements and upgrades out if you only get the registration fee once? That may sound altruistic, but you're really just harming yourself and putting yourself in a very difficult situation a few years later.
We did this for our first haxies when they came out. And guess what, this single decision has hit us greatly since then. Don't get me wrong, we love improving software, but if we don't charge for an upgrade ever (which is the case for WindowShade X or FruitMenu), we are going to die as a company eventually (since this is a full time job for all of us). Luckily, we have plenty of products, and they are quite popular, so that keeps us running, despite the initial mistake of offering upgrades for free. Plus, we no longer offer that for our stuff. Granted, we have never charged an upgrade fee yet, but eventually we will.
If you're a user, sure, free upgrades for life sound great, but come to think of it - if a certain software title promises you that, expect the maker to exit the business or abandon that particular product sooner or later. They simply can't support themselves and justify adding features when they know they will never get that additional cash in. So why bother making a 2.0 if you know all the hundreds of hours of your hard work are going to be not paid off? I know too many examples of that to count.
The being said, if you are a developer, also heavily justify when to charge an upgrade fee. Don't do it too often or your loyal users will be pissed and you'll lose customers. I used to own a software that charged me an upgrade every 3 or 4 months. I no longer bother, since there are really no new features in each paid upgrade, and charging for the bugfixes is uhhh... Let's not get into that.
So, please, please, don't offer lifetime free upgrades. I want you all to stay alive and healthy. Don't make that first step onto the road to destruction, no matter how tempting it may sound.
There was a pretty heated discussion on the blogosphere on Smart Crash Reports' install API doing a silent installation of the tool.
Granted, we initially left it up to the developer to alert/ask the user about Smart Crash Reports and whether they want to install it. However, it turned out that the ease of not writing a dialog at all has caused many (including ourselves, heh) to skip that step.
So here it is, a universal build complete with the SDK that now puts down a nice dialog box asking the user whether they want to install or not when the developer calls UnsanitySCR_Install():
If the user dismisses the dialog by clicking the "Don't Install" button but does NOT check the "Don't Show Again" checkbox, then they will not see the dialog for next 24 hours, no matter how many times UnsanitySCR_Install() will be called by application(s) as to not annoy the user with too many dialogs.
Other than that, this version has been tested and runs on the Intel and PowerPC boxes, and generally is one step away from the release. The only thing missing is localizations on the above mentioned dialog box. Give it a try!
http://www.unsanity.net/beta/smartcrashreports-11b1.dmg
Remember that game you used to play as a kid where you had to sit in the middle of your circle of friends and watch as they passed a button around? The idea being they would only sometimes actually pass the button from one hand to the other and then you're supposed to guess who has it now.
Do you ever get the feeling everyone on the web is playing a big game of "pass the button"? It seems like everyone is watching the rest of the web world to try to spot the button. Lately a couple of the button holders seem to be Digg.com and MillionDollarHomepage.com. They're the latest to come up with something fairly simple and/or a twist on an old idea and profit in a big way from it. Now there are all sorts of people trying to grab that button.
Watching the success of google/yahoo ads on a pile of completely useless sites amazes me also. It seems everyone on the internet is just swapping cash. You come to my site and I'll try to drive you away via an ad where, many times, I'm simply taken to another site with yet more ads. Everyone swaps cash and clicks, but most of the time it seems to be all for intangible nothings.
Steven chimes in on the greatest-idea-I-wish-I-had. I think Steven is on to something here...
...Not to be one to pass on a good game of Button Button, Who's Got the Button, I'll take the plunge and follow up Steven's offer with one better. Yes, I will give you 50% off his already incredible rate and sell you, the ever vigilant button watching VC/marketer, a whopping 1000 x 1000 pixel ad for $250,000 dollars. You know this half-off thing is big headlines right? Big ol' button waiting to be spotted right here!
So, who's next? The way I see it, if we keep offering half-off rates, someone is going to get a sweet deal on a giant ad very soon. ;)
Alright, my RSS reader just said there are 2 new stories on Digg. I'm off to go click some stuff.
A big blank white page here and Matthew Levine reminded me to finish a post I had started a month ago about quality software. Matthew was kind enough to offer me some additional help after I was stumped with a problem while I was trying to implement a web site using his technique recently published as In Search of the Holy Grail on ALA (yes, he has caught enough flak for the phrase already and no, he didn't coin it anyway). If you have interest in CSS layout and design, his article is well worth your time, go check it out.
He posts about Switching to TextMate. Making the switch seems to be the all the rage these days. Here's my take as to why:
Sometimes there is a piece of software so good that I'm immediately blown away and want to buy it on the spot. It looks great, it does cool things, and it fills a niche I need. This kind of software usually gets forgotten by me after the wow-factor and I don't use it as much later.
Other times I find software that is nice. It's okay. I try it out and think "neat". Most of the time that software just finds it's way into my bloated Applications directory and gets trashed many months later. However, sometimes a piece of software starts to grow on me and I get more impressed the more I use it. BBEdit was one of those.
Lately, on urging from several people, I have started using TextMate. (which, btw, supports SCR now) TextMate was deceptively simple at first glance. Maybe it was just me, but I didn't see much to get me excited about it. But after having used it for a few weeks, I'm amazed. Every time I think "I wish it could do x feature", I find that it already does! TextMate is way ahead of me and already knows my meager needs and is ready for me to graduate to bigger and better needs too! We definitely don't lack for great choices in text editors for the platform.
Software that is quietly and elegantly meeting the needs, even those unanticipated, is what quality in software engineering is all about.
Matthew pointed out some new "can't live without" features of TextMate and some "miss em" things from TextWrangler. I'm right with him on most of those. By far my most missed feature is that Block Undo magic. Incredible how useful that is and how much I miss it now.
Finally, speaking of quality software, IE6 is not. Well, when it comes to CSS support anyway. I am really sick of trying to make this new project (an Unsanity project that hopefully will be seen in the not too distant future) work in IE. Sometimes tables are very very tempting. Float this!!!! Also, I tried IE7 just for fun... and I'm not impressed. Couple million in budget can't do better? Apparently Rentzsch and others agree. I'd happily settle for a complete lack of innovation in exchange for Firefox/Safari/etc level standards support. Not that that would help any of us for the next several years... ah, legacy support.