Exceptional AppsAugust 24th, 2012
Today I went to launch VMware 4.1.0 on my OS X 10.8.1 Mac and was met with this surprising refusal to open:
Well, that’s interesting. Mac OS X supports the ability for applications to specify in their “Info.plist” files the minimum system version they require, but as far as I know there are no keys for specifying the maximum system version. Mac OS X will display a similar failure when an application is so old that it doesn’t contain code that was compiled for the appropriate CPU on the computer, but the code in this VMware 4.1.0 executable is 64-bit Intel code that my Mac should be able to run.
Now it so happens that VMware 4.1.0 shipped with a bug that many folks have found convenient. Apple officially forbids the virtualization of Mac OS X “client” operating system releases prior to 10.7. If one was inclined to defy this, then having a copy of 4.1.0 around to run virtual machines would be pretty handy.
Knowing that this version of VMware inadvertently defies Apple’s virtualization policy, and believing that there’s no way for the app to be identifying itself as incompatible with the current version of Mac OS X, I immediately jumped to the conclusion that Apple was “blacklisting” the app for political reasons:
Whoah, did Apple blacklist VMware Fusion 4.1.0 as of 10.8.1? skitch.com/danielpunkass/…
— Daniel Jalkut (@danielpunkass) August 24, 2012
Damn you, Apple! I’ll show you, I’ll just jump into the terminal and run it from the command line. Doing so showed me a very fast, very efficient door to the immediate panicking and restarting of my Mac. Wow, they really don’t want me to open this app!
Upon restarting and reviewing the panic log, I realized the crash was actually related to VMware’s kernel extension. So in all likelihood, the app has an incompatibility with 10.8 and Apple is blocking users from casually opening it as a favor and not as punishment to VMware or its users.
How does this kind of “blacklisting” occur on Mac OS X 10.8? I suppose in the future we might see restrictions that tie in to the new Gatekeeper signing system, but that is of no help if the targeted apps are not signed. The current mechanism is in the form of a crude XML file installed by Apple in your System folder:
Take a look, it’s pretty interesting! In this file you’ll find all manner of policy amendments, all based on the bundle ID of the targeted application. Search the file for a section labeled “MinimumVersionRequirements” and you’ll discover a long list of bundle IDs and corresponding version numbers. When you double-click an app to open it in the Finder, among the other checks the system does, it looks for an entry in this list for the appropriate bundle ID and, if found, only allows the app to launch if its bundle version is the same or higher than the value listed.
In the case of VMware Fusion’s entry, it lists 536017 as the minimum. I don’t have it installed, but I suspect this is the bundle version for VMware 4.1.3, the last officially supported version of VMware 4 on 10.8.
But VMware also earns the distinction of being the only app in the file to take advantage of a keyed value “VersionRange”:
<key>VersionRange</key> <array> <string>683826</string> <string>683827</string> </array>
I don’t know exactly how this is interpreted, but I suspect it’s a range of bundle versions that should be considered incompatible with the system. In this case, I suspect Apple has determined that there is a problem with a specific version of VMware Fusion 5. They can’t set the minimum version to the latest version of VMware without cutting out support for 4.1.3, so the VersionRange technique lets them surgically remove support for this specific version.
Elsewhere in the file you will find other interesting policy amendments, including a long list of apps on which the LSFileQuarantineEnabled flag is explicitly turned on. This flag ensures that whatever files are created by these apps, they should be “quarantined” to cause the default protections e.g. for Gatekeeper policies to be enforced. Not surprisingly, the list of bundle IDs are all web browsers and torrent downloaders. Apple’s using the policy amendment here to say: even if the developers of these apps haven’t taken care to set the LSFileQuarantineEnabled on their own, the system should treat any files created by these apps as if they are “files downloaded from the web” and subject them to greater scrutiny than the files created by other apps.
As Apple becomes increasingly involved in the vetting of which software should be sold to, or allowed to run on customers’ computers, it’s worth considering whether they will be tempted to use these powers for less honorable goals. I would not have been surprised if Apple’s blacklisting here had been for non-technical reasons, but in spite of my initial paranoia, the Exceptions.plist file seems to only contain amendments that are genuinely for the good of users and developers.
August 24th, 2012 at 12:40 pm
730298 is 4.1.3
536016 is 4.1.1
683185 is 4.1.2
529802 is 4.1.0
August 24th, 2012 at 12:43 pm
I’m running VMware 4.1.3 just fine on Mountain Lion.
August 24th, 2012 at 12:48 pm
Jeff: there is no reason you shouldn’t be able to :)
August 24th, 2012 at 1:57 pm
There is no doubt that they’ll be tempted to do so, they likely already have. Will they give into the temptation? I hope not, if for no other reason out of concern that someone will find out. With so many modes of mass communication if they do this word will spread like crazy, and not likely to be in their favor.
In some respects I hope this mutually assured destruction (do something bad vs. have everyone scream about it) will help keep those decision makers in check when they are tempted.
August 24th, 2012 at 2:30 pm
There is indeed a maximum system version key supported in plist files. Do your homework.
August 24th, 2012 at 2:37 pm
@bobx – It would have been noble of you to link us to the documentation, instead wasting space in my comments with pure jerkiness.
August 24th, 2012 at 2:43 pm
Fusion is on Apple’s do not break list last time I checked – note, I don’t work on Fusion anymore. I would suspect they found the kernel extension flaw in their testing and didn’t want the kernel panic (rather than the ill willed reason).
It looks like this particular exceptions file was introduced in this version of the system booter:
But the quarantine (with some variation of features) has been around for a while:
August 24th, 2012 at 2:47 pm
I also hit this dialog on 10.8, and likewise realized Apple’s move was the only safe choice. It could be the case that Apple discussed the situation with VMWare and they mutually agreed Apple adding the exception was the best course of action.
Luckily the ServerVersion.plist hack still works if you change it while booted into 4.1.0 on Lion.
August 24th, 2012 at 3:03 pm
This mechanism was actually introduced (and first employed) with Lion.
August 24th, 2012 at 3:06 pm
Ryan: are you sure it’s that new? I seem to recall the Exceptions.plist file or something like it way back when I worked on 10.2.
August 24th, 2012 at 3:48 pm
On one of my MacBooks, I had Fusion 3 installed. When I upgraded to ML, I had to upgrade Fusion.
However, on my second MacBook, I upgraded to ML and then did a first-time install of Fusion 4.1.3. It’s running with no complaints…
August 24th, 2012 at 4:14 pm
Exceptions.plist certainly isn’t new, but I recall its use being extended in 10.7 (or maybe it was 10.6) to better catch incompatible software.
August 24th, 2012 at 4:15 pm
The bundle version is populated with an internal build identifier, Jason posted the decoder ring above.
The VMware Fusion 4.1.x line includes many Mountain Lion related fixes as mentioned in the release notes here:
These include kext fixes. The release notes are necessarily light on details since Mountain Lion was not released at the time they were written. If you’re running Mountain Lion you really should be on VMware Fusion 4.1.3, or VMware Fusion 5.
VMware Fusion Product Manager.
August 24th, 2012 at 5:30 pm
Ryan: this definitely predates Lion. I remember it being around when I was working on Mac OS X.
August 24th, 2012 at 8:52 pm
I think those exceptions appeared in Leopard, perhaps version 10.5.1. Older versions of Safari stopped working with a similar message at that time, and I had to change the bundle identifier for Multi-Safari. At that time, the Exceptions.plist file was in the LaunchServices framework.
August 24th, 2012 at 10:46 pm
FWIW, the exceptions were definitely present in some form in 10.5.0; Apple told us in advance they were opting Camino into Quarantine during 10.5″™s development (although they actually opted in the old Navigator bundle ID, not the Camino one we had been using since Camino 1.0 :-P ).
August 26th, 2012 at 2:17 pm
There are several Adobe apps with bundle identifiers that begin with com.yourcompany in that file. How on earth did they ship two apps without naming the bundle identifier properly? It seems like a joke.
These 4 are clearly Adobe’s:
Don’t know what this one is, but it’s apparently a role playing game:
This is probably Lego Star Wars:
Also don’t know what this one is either, some sort of utility: