Sunday, September 15, 2013

expired certifications on mac os packages

Apparently Apple leaves up packages with fairly early cert expirations hanging around, and you get mysterious crap problems trying to load them.

I found two approaches. 

One is to set the time on your system to a date when the cert has not expired.  this will be okay if the certs created during install do not also expire.  That approach worked fine for this problem, installing xcode 3.6.2 on 10.6.8 Snow Leopard.

A second approach is to fix the certs.  Two postings from "manageingosx" are copied explaining the problem and a fix.

stackoverflow   fix
------------------
http://stackoverflow.com/questions/10002393/instaling-xcode-3-2-5-on-osx-10-6-8-produces-the-error-the-operation-couldnt

11 down vote accepted
I also had the problem installing the downloaded version of XCode 3.2.6 from Apple, checked the log and got the "untrusted" error and found my way here to discover the Package Signature issues. Some of those tools only work on Lion though, and much of this is catch 22 for people as we are using 10.6 and so have to use Xcode 3.2.6...
Anyway, to cut a long story short, change the system date back to Feb 2012 (before the certs expired in March 2012) and then install.... worked fine for me, such a simple solution - far too long to get there though...
EDIT : Sorry, only just clicked though to see your link about the date/time, I went straight to the repackager. If it's okay, I'll leave this here as it gives a direct answer to the question for people like me who have just found this on Google etc

------------------


http://managingosx.wordpress.com/2012/03/24/package-apocalypse/

http://managingosx.wordpress.com/2012/03/24/fixing-packages-with-expired-signatures/


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.

-----------

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.

For example, the packages included in the iLife ’11 Install DVD have expired signatures. The only “replacement” available would be the Mac App Store versions of the iLife 11 apps. Not all iLife ’11 apps from the DVD have App Store equivalents, and distributing the App Store versions is a whole different set of issues.
So the ideal solution here is to somehow fix the packages with expired signatures so they will work with your software distribution mechanism. It turns out that you can do this with an Apple-provided tool — pkgutil.

pkgutil --expand SomeFlat.pkg /tmp/SomeFlat.pkg
pkgutil --flatten /tmp/SomeFlat.pkg SomeFlatFixed.pkg

Expanding and reflattening a flat package has a side-effect of removing the package signing. the command-line installer tool will happily (at least as of this writing) install unsigned flat packages.
So there you have it — a way to fix packages broken by the Package Apocalypse. But it’s a tedious process. To help, I offer yet another tool — flatpkgfixer.py.
This tool will remove package signing either from a single flat package:

./flatpkgfixer.py /path/to/expired.pkg /path/to/new_fixed.pkg

or can fix up an entire disk image containing packages:

./flatpkgfixer.py /path/to/iLife11.dmg /path/to/iLife11_fixed.dmg

This tool is brand new, and could very well have bugs, but I hope it’s useful to some!

2 comments:

  1. Apologies, but are their instructions on how to run this? I.e. for novice like me? I need this for ilife 11 installer....

    Much appreciated

    ReplyDelete
  2. There are links to the fixes I found.

    Certifications have time limits in them. Most nice manufacturers like Apple, Dell, IBM and so forth sign them and have very far in the future (to the max internal date linux / posix / unix can handle, so they will effectively never expire.

    These signatures are designed to allow the OS to tell if the installed data has been altered and protects checks on the programs to be installed.

    but Apple made things for OS's that are not that old, like the C compiler package expire in just a couple of years. So even if you downloaded and saved the Xcode installer or whatever, it is useless now for casual use because these certificates are invalid because of the dates

    One fix is to get around the problem that the certificates are invalid. The other is to fix the certificates.

    There is more information than I can help with in doing these approaches in the links I included to the original articles.

    the StackExchange people have nice information, but are not very nice people to novices. You will probably have your feelings hurt if you need more than perusing and reading their entry. However they frequently have a lot of information.

    ReplyDelete