Fixing packages with expired signatures

In my previous post, I provided a tool to enable you to check your collection(s) of packages to determine if any are affected by the Package Apocalypse.

But what to do once you’ve found packages with expired signatures? If Apple has provided an updated replacement package at http://support.apple.com/downloads/, it’s probably best to replace the package with the expired signature with the updated one.

But that might not always be possible — Apple has not provided replacements for every package that has been affected, or the replacement might not be practical to use.

Advertisement

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.

Cauliflower Vest: FileVault 2 management for enterprise

Google’s MacOps team has released a new open source toolset for managing FileVault 2 for the enterprise: Cauliflower Vest.

Cauliflower Vest offers the ability to:

• Forcefully enable FileVault 2 encryption.
• Automatically escrow recovery keys to a secure Google App Engine server.
• Delegate secure access to recovery keys so that volumes may be unlocked or reverted.

http://google-opensource.blogspot.com/2012/02/cauliflower-vest-end-to-end-os-x.html

http://code.google.com/p/cauliflowervest/

FileVault notes

I’ve published an article on FileVault deployment at macenterprise.org. It’s here.

You can get a PDF version here.

Startup Items Security

Here is an article I did for MacEnterprise.org, responding to a recently published warning of an OS X security vulnerability by rixstep.com. Bottom line: nothing to worry about.