Unarchiver + CodeSignatureVerification

[Gregory Neagle]

I uncovered an interesting issue today:

https://github.com/autopkg/killahquam-recipes/pull/3

If you have recipes that do CodeSignatureVerification and expand their payload from a zip or other archive format, you might want to check to make sure the Unarchiver step has “purge_destination” set to true.

I was getting CodeSignatureVerification errors on the Slack recipes, which looked like this:

CodeSignatureVerifier

{'Input': {'DISABLE_CODE_SIGNATURE_VERIFICATION': False,

           'input_path': u'/Users/gneagle/Library/AutoPkg/Cache/local.munki.Slack/Slack/Slack.app',

           'requirement': u'identifier "com.tinyspeck.slackmacgap" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = BQR82RBBHL'}}

CodeSignatureVerifier: Verifying application bundle signature...

CodeSignatureVerifier: /Users/gneagle/Library/AutoPkg/Cache/local.munki.Slack/Slack/Slack.app: a sealed resource is missing or invalid

CodeSignatureVerifier: file added: /Users/gneagle/Library/AutoPkg/Cache/local.munki.Slack/Slack/Slack.app/Contents/Frameworks/Growl.framework

Code signature verification failed. Note that all verifications can be disabled by setting the variable DISABLE_CODE_SIGNATURE_VERIFICATION to a non-empty value.

Failed.

It turns out that a previous download included the Growl.framework. An earlier run of autopkg had unarchived the Slack.app containing the Growl.framework. The current release does not contain the Growl.framework. But because the .download recipe did not purge the destination directory when unarchiving the .zip download, the new contents were written over the top of the previous unarchive, resulting in the Growl.framework still being present in the destination directory, and then leading to CodeSignatureVerification failure.

This has other possible effects.

Even if you were not using CodeSignatureVerification, you might be building a package or disk image from the results of an Unarchiver step — if you failed to purge the destination as part of Unarchiving you could include files in the package or disk image that had been removed in the current release.

Moral of the story: unless you have a good reason not to, you should set “purge_destination” set to true in Unarchiver steps in your autopkg recipes.

If you maintain autopkg recipes, please take a few moments to look at your recipes for possible issues of this nature.

-Greg

[A.E. van Bochoven]

Saw this too, thanks for looking into this. 

Arjen

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "autopkg-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autopkg-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.