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.
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
[…] Managing OS X Trials and Tribulations of an OS X Administrator « Package Apocalypse […]
is –check-signature only a pkgutil option in 10.7? doesn’t seem to be present on 10.6.8 here.
Looks like you’re right – it’s a new option in Lion’s version of –check-signature. I’ll update the post.
[…] Package Apocalypse by Greg Neagle […]
[…] Greg Neagle’s checkPackageSignatures and flatpkgfixer scripts are extremely helpful here. checkPackageSignatures will help you find […]
[…] – 3-24-2012: If you are reading this after Friday, March 23 2012, make sure to remove iLife 11′s package signing using Greg Neagle’s flatpkgfixer script prior to using the repackaging procedure […]
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?
See this: https://groups.google.com/forum/?fromgroups#!topic/reposado/MIuRFSvd44A
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
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?
It doesn’t like it. But you can ignore it.
if you let me know how… i will be the happiest 🙂
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.
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.
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.
No harm — just if trips up or fails on items that aren’t installation packages, don’t worry about it.
BTW some folks already ran it through InstallESD.dmg from AppStore 10.7.3 installer and found 2 packages with the expired certificate.
RemoteDesktop.pkg & SIUResources.pkg were the ones affected.
to be precise it was 10.7 installer downloaded from AppStore today at 1pm PST.
[…] https://managingosx.wordpress.com/2012/03/24/package-apocalypse/ https://managingosx.wordpress.com/2012/03/24/fixing-packages-with-expired-signatures/ […]
[…] Neagle has released to extremely useful scripts, checkPackageSignatures and flatpkgfixer. checkPackageSignatures will help you find expired certificates in your […]
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.)
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.
[…] behind munki – managed software distribution) has released two extremely useful scripts, checkPackageSignatures and flatpkgfixer. checkPackageSignatures will help you find expired certificates in your […]