Gruber does a snow job on Snow Leopard

John Gruber holds Apple blameless for shipping Mac OS X 10.6.0 with an outdated version of Adobe Flash Player, a version with known vulnerabilities that have been exploited in the wild. The essence of his absolution is the following timeline: “Adobe released version 10.0.32.18 of Flash on July 30. Snow Leopard went GM on Friday August 7″.

It is true that Adobe released Flash Player 10.0.32.18 to the public on July 30. However, with regard to the version of Flash Player included with Snow Leopard, that date is largely irrelevant. On July 21, Adobe released a security bulletin to the public: “Adobe is aware of reports of a potential vulnerability in Adobe Reader and Acrobat 9.1.2 and Adobe Flash Player 9 and 10.” The next day, there was a public follow-up: “A critical vulnerability exists in the current versions of Flash Player (v9.0.159.0 and v10.0.22.87) for Windows, Macintosh and Linux operating systems, and the authplay.dll component that ships with Adobe Reader and Acrobat v9.x for Windows, Macintosh and UNIX operating systems. This vulnerability (CVE-2009-1862) could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild via limited, targeted attacks against Adobe Reader v9 on Windows. We are in the process of developing a fix for the issue, and expect to provide an update for Flash Player v9 and v10 for Windows, Macintosh, and Linux by July 30, 2009″.

It is crucial to note that these were all public releases. Since Apple ships Adobe Flash Player with Mac OS X, Apple and Adobe undoubtedly have a private relationship. One would presume that Adobe privately discloses security vulnerabilities in the OS X version of Flash Player to Apple in advance of public announcements and that Adobe privately provides Apple with versions of Flash Player to test on OS X prior to public release. If these things do not occur privately, then both companies ought to be blamed for failing to follow industry best practices.

I’m not sure where Gruber gets the August 7 date. (Perhaps an email from Phil?) Snow Leopard build 10A432 was seeded to eligible ADC members on August 12. If Apple had already declared build 10A432 the GM before seeding it to developers for testing, that would be completely irresponsible (though sadly, not unprecedented). In any case, if the 10A432 seed had turned up a show-stopping bug, Apple could have un-declared it GM. Is allowing an attacker to take control of a system via a web browser not a show-stopper? Gruber asks, “Should Apple have postponed Snow Leopard for another month?” Despite the rhetorical nature of the question, I’ll answer: maybe they should have. Or at least, they should have postponed it 4 days. At WWDC, Apple told us that Snow Leopard would be released in September. Last time I checked, August 28 is not in September. Even delaying Snow Leopard a month would have allowed Apple to ship on time, in September.

Setting aside these more relevant dates, let’s just accept Gruber’s 8-day window for the sake of argument. “Does anyone really think that Apple should have replaced the single-crashiest piece of software in Mac OS X with a new untested version just eight days before going GM?” Yes, I do. We’re not talking about a major update here — obviously Apple should not switch from Flash 9 to Flash 10 eight days before GM. Apple had already pulled the trigger on Flash 10 for Snow Leopard. When security vulnerabilities come to light, fixes must be released quickly. Eight days of testing the update from Flash Player 10.0.22.87 to 10.0.32.18 really should have been sufficient for Apple. If a critical vulnerability was discovered in Mac OS X, Apple should be able to ship a fix within 8 days, if not sooner. Indeed, there were 8 days between Adobe’s security bulletin and the release of the updated Flash Player.

Apple’s record for shipping timely fixes to security vulnerabilities is poor. For example, Apple ‘distinguished’ themselves by being the only vendor in the world to fail to join the coordinated effort to release a fix for the Kaminsky DNS vulnerability on all platforms on the same day. Instead, Apple took its own sweet time, which was particularly egregious for Mac OS X Server customers. (Though I use OS X on my personal computers, I’m glad my web host does not use OS X on their servers.) I personally was aware of the ‘Safari RSS’ vulnerability for months while it remained unpatched and could have easily exploited any visitor to my web site if I had wanted. Fortunately for you, I’m not malicious. Not criminally malicious, anyway.

16 Responses to “Gruber does a snow job on Snow Leopard”

  1. ssp says:

    Pretty much the same thoughts I had when reading that bit of apologism. Two thoughts sprang to mind:

    1. Even if Apple did not manage to ship the latest version of Flash with their OS install, most of the ‘outrage’ seemed to be about the X.6 updater _downgrading_ the installed version. It should be hard to find a parallel universe in which that makes sense.

    2. What exactly do people think that Apple do in terms of quality control that they couldn’t manage to achieve within a week? Even in their own code there are plenty of untested areas and if you’re using non-English localisations it is blatantly obvious that Apple consider it perfectly acceptable to sell software which hasn’t even been looked at (by a human who is awake and speaks the language), so what exactly will they do with the Flash plug-in before shipping it.

    Of course, in the days of ClickToFlash, the practical relevance of this seems negligible. It would be interesting to read what people commented had Apple not shipped Flash at all with their OS.

  2. Charles W says:

    I unsubscribed from Gruber’s RSS feeds some time ago, and I have to say that my days are happier for it.

    I got sick and tired of his relentless pro-Apple fanboyism, his snide personal attacks, and the one-sided nature of his ruthless commentary.

    it comes as no surprise whatsoever that Gruber would automatically take Apple’s position on the Flash issue.

  3. [...] Jeff Johnson: Snow Leopard build 10A432 was seeded to eligible ADC members on August 12. If Apple had already declared build 10A432 the GM before seeding it to developers for testing, that would be completely irresponsible (though sadly, not unprecedented). In any case, if the 10A432 seed had turned up a show-stopping bug, Apple could have un-declared it GM. Is allowing an attacker to take control of a system via a web browser not a show-stopper? [...]

  4. I still like John and most of what he says, but I don’t agree with his position on this issue at all.

  5. Stephen Hoffman says:

    Replacing software in a near- or in an actual GM is precarious practice. Any OS-level development requires trading off the available staff, testing resources, and the risks and release schedule. Always has. Always will. And you freeze feature changes as early as you can, and you then prioritize fixes in terms of schedule and stability and risk and testing coverage. And you test and test and test.

    Does anyone want a broken Adobe Flash in a GM or (worse) corruptions or instabilities introduced elsewhere in the environment? Having been in (many) these discussions for OS-level release work (not at Apple), and a conservative engineering development practice (usually) carries these decisions. Experience has led me to be skeptical around claims of entirely isolated and modular code, too.

    After the realization that a fix is not going into the GM is grokked, the discussion then (usually) becomes “and how quickly can the fix be tested and made available?” And “will we have systemic risks or exposures in the wild prior to that?”

    The whole GM discussion here is somewhat of a canard, too. An SL Server software licensing fix didn’t make the GM, after all. The better question is “when is the fix going to be tested and available?” Faster is better. Faster and unstable is worse. And you can only go as fast here as you have staff for and testing coverage for. But a GM? That’s substantially more than a vehicle for a fix.

    Load ClickToFlash, and move on.

  6. Daniel says:

    See Gruber’s follow-up. Seems the SL flash version is different from the one in the security bulletin.

  7. Mike Ash says:

    But still much older than the version which contains the fix. There is no reason to assume that Apple’s special version has it, and every reason to assume that it does not.

  8. Joshua Ochs says:

    Clearly no one here has ever dealt with real world software development. Never mind the concept of feature freeze, regression testing, or having a release schedule for your software.

    But by all means, continue with your armchair commentary.

  9. Jeff says:

    Joshua, you are correct, neither I nor any of the commenters here has any real world software development experience. My apologies. What the heck were we thinking? We will now shut our stupid mouths.

  10. Charles W says:

    Dear Joshua, please educate yourself before posting in future. The blogger is an engineer with Rogue Amoeba, a company which makes and ships “real” software.

    I’m also a developer and publisher of Mac software. Are you?

  11. Andy Lee says:

    Jeff, there’s only one point here I take issue with:

    “If Apple had already declared build 10A432 the GM before seeding it to developers for testing, that would be completely irresponsible [...].”

    This is true if the sole purpose of developer seeds is to discover bugs in the seed that might be showstoppers. But there is another purpose, which is to allow developers to make sure their apps can be ready to ship when the OS does go GM, whenever that may be.

    I think your point that “Apple could have un-declared it GM” still stands. From our point of view 10A432 would just have been another seed that turned out not to be GM. Even if they had told us it *was* GM, they could have un-GMed it.

  12. Jeff says:

    Andy, I agree that’s an important part of seeding. However, for any sane OS vendor, this would be the procedure when they have a release candidate build:

    1. Seed the release candidate to developers
    2. Tell developers that it’s a release candidate
    3. If no show-stopping bugs are found, tell developers that the release candidate is GM
    4. Tell developers the release date
    5. Tell consumers the release date

    Unfortunately, Apple skipped steps 2 through 4. Indeed, at no point prior to or even on August 28 did Apple ever tell us that 10A432 was either a release candidate or the GM.

  13. Andy Lee says:

    Yeah, I remember at least once they’ve told us that a seed was the GM, though I don’t remember if it was before or after the release date. Odd that they didn’t do it this time. The Developer Connection site still calls it a preview build.

  14. Clark says:

    Why not just put the new version of Flash in software update and make software update do what MS does and check immediately during the install process to install any critical updates?

    I’m not sure the way the discussion is going makes sense. (Withdraw the GM) Rather I think there’s a deeper issue of what to do if a serious flaw is found after disks are on the shelves. While Apple has been lucky there is the chance of something happening ala many XP installs where systems are compromised within minutes of being installed if older media is used.

    The solution just has to be to make a security update check as part of the installation process. The fact Apple doesn’t do this is worrisome.

  15. You don’t do an upgrade of a third party component in the last week before shipping something the size of Snow Leopard. Especially a component with the record that Flash has.

    You can place the blame for it wherever you want, but expecting something different is not rational.

  16. Jeff says:

    Steven, as I explained, “the last week before shipping” is an invention of John Gruber’s mind which has little basis in reality. In any case, however, note that Adobe shipped an update within a week, and the size of Snow Leopard pales in comparison to the entire install base of Flash Player.

    Also, I find Gruber’s and your argument about “the record that Flash has” to be very curious. Essentially, the argument that Flash Player is known to be buggy, so therefore it shouldn’t be updated? It seems to me that’s the opposite of what should happen.

    Again, we’re not talking about a major update to Flash Player, for example from 9 to 10, but simply a fix for one security bug. Although I should say, for many users who upgraded from Leopard to Snow Leopard, they were automatically and unknowingly upgraded from Flash Player 9 to 10 by Apple. The automatic upgrade from Flash 9 to Flash 10 also occurred in Leopard via Security Update 2009-005, even to those users who had already installed Flash Player 9.0.246.