Package Apocalypse

Earlier this week a certificate Apple had used to sign flat packages over the last couple of years or so expired. This caused Apple to have to reissue a lot of update packages. This greatly affected sites running an Apple software update server, either Apple’s flavor, or the open-source Reposado replacement. See http://support.apple.com/kb/HT5198 for more info on how this affects Software Update.

This also affects some update packages you might have downloaded from http://support.apple.com/downloads. If they are flat packages, it’s possible they may also be signed with an expired certificate. Such packages can be manually installed – Installer.app will display a warning, but you can choose to ignore the warning and proceed.

But if you have a mechanism that uses Apple’s command-line installer tool, these packages will fail to install. This will affect popular tools like InstaDMG, DeployStudio, Apple’s System Image Utility, and any software distribution mechanism that makes use of the command-line installer tool. Some examples include Munki, Casper, and AbsoluteManage.

Worse, this problem affects at least one software package originally distributed on DVD: iLife ’11. If you’ve imported the packages for iLife ’11 into your software distribution mechanism, they may now fail to install because of the expired certificate.

I am working on a tool to fix affected packages. (UPDATE: see this post.) But in the meantime, if you want to get an idea of how many packages you have that are affected by this issue, you might want to make use of a tool I wrote. It will scan a directory of packages or disk images containing packages and print information on any packages with bad or expired certificates.

Get it here.

The tool relies on a pkgutil option introduced in Lion, so you’ll need to run this on Lion!

An example of checkPackageSignatures.py in use:

./checkPackageSignatures.py /Volumes/LaCie/InstaDMG/pkgs-10.6.8/

/Volumes/LaCie/SIU/Snow Leopard/pkgs-10.6.8/Install iTunes.pkg:
Package "Install iTunes":
Status: signed by a certificate that has since expired
/Volumes/LaCie/SIU/Snow Leopard/pkgs-10.6.8/JavaForMacOSX10.6Update4.pkg:
Package "JavaForMacOSX10.6Update4.pkg":
Status: signed by a certificate that has since expired
/Volumes/LaCie/SIU/Snow Leopard/pkgs-10.6.8/MacOSXUpdCombo10.6.8.pkg:
Package "MacOSXUpdCombo10.6.8.pkg":
Status: signed by a certificate that has since expired

Use this tool to scan any collection of packages you have to see which are affected by this issue. If a replacement package is available from Apple, you should replace it. If there is no replacement, there is hope. Keep checking back here for an update soon.

Advertisement
Package Apocalypse

25 thoughts on “Package Apocalypse

  1. Don Montalvo says:

    These are the kinds of bloopers that gives the Wintel guys ammo to beat up on Apple when we have our team meetings. To be honest, Apple deserves the embarassment. Do you know how long it will take for our internal Apple SUS servers to re-cache all the available packages…and from there to replicate to the other servers on our network? Our clients have fast connections, but it still means critical patches are delayed while everything refreshes.

    Don Montalvo

  2. willpolley says:

    For Reposado, do you recommend the same process as Apple and completely repull the update files?

    Maybe Reposado is smarter than Apple’s update server?

  3. nick says:

    FYI- there’s 2 expired packages in the Lion Installer being distributed by the App Store as of 12:30 pm PST today. I re-downloaded it when I started having problems with Casper imaging today . . . Here’s the output from greg’s checking script when run against the InstallESD’s packages directory:
    Last login: Mon Mar 26 13:04:41 on ttys001
    nbkali-mba:~ nbkali$ /Users/nbkali/Downloads/checkPackageSignatures.py /Volumes/Mac\ OS\ X\ Install\ ESD/Packages
    /Volumes/Mac OS X Install ESD/Packages/RemoteDesktop.pkg:
    Package “RemoteDesktop.pkg”:
    Status: signed by a certificate that has since expired
    /Volumes/Mac OS X Install ESD/Packages/SIUResources.pkg:
    Package “SIUResources.pkg”:
    Status: signed by a certificate that has since expired

  4. Cem says:

    Hi Greg, thanks for this superb tool.
    But I seem to having problem running against my package repository. It just hangs there very very long time and nothinelse happens…

    /Volumes/CasperShare/Packages/10.6.4 Vanilla.dmg:
    Could not open package: /private/tmp/dmg.09cnHX/Library/Receipts/BSD.pkg

    am I doing something wrong? or it just doesn’t like the BSD.pkg?

      1. Cem says:

        one of the guys from jamfnation said that it took for awhile for him to pass the BSD file.. I will run it overnight, as I have a quite few OS DMGs.

      2. Don’t scan disk images that don’t contain installers. “0.6.4 Vanilla.dmg” sounds like a restore disk image, not something that gets fed to /usr/sbin/installer.

        Notice that it’s scanning /Library/Receipts/BSD.pkg — that’s _NOT_ an installer package; it’s a package receipt.

        checkPackageSignatures was meant to scan flat packages and disk images containing flat packages to install. Disk images meant for ASR-style imaging should not be scanned.

  5. Cem says:

    Thanks Greg! I am sure there were be no harm to run it though. Correct me if I am wrong here please. It just saves me a lot of time to go through 100s of items from packages repository…. all I need is to identify expired packages.

      1. Cem says:

        BTW some folks already ran it through InstallESD.dmg from AppStore 10.7.3 installer and found 2 packages with the expired certificate.

  6. The utility gives me no output at all, no matter what package or directory I put through it. I strongly suspect one of my packages does have a signing issue as it won’t build into InstaDMG, so I’m curious if anyone else has had issues with this script. Also I suggest to Greg that the script should probably provide output whether the packages is positive or negative for problems. (Or maybe it already does, but I’m not seeing any.)

    1. I’m going to suggest that since there is no output, no package in the given directory has an expired signature.

      If you’d like to double-check, try using pkgutil in Lion:
      pkgutil –check-signature

      If you’d like to modify the behavior of checkPackageSignatures.py: it’s a Python script. You can modify it any way you’d like.

Comments are closed.