Gatekeeper Code Signatures and 10.9.5

jescala
Contributor II

In case you have not heard, the forthcoming 10.9.5 update will introduce a new requirement for app signatures that may present some problems depending on your client systems' Gatekeeper settings:

http://www.tuaw.com/2014/08/04/apples-changes-to-app-signing-could-leave-some-apps-blocked-by

I was curious what the impact would be with our base configuration so I came up with the following report script you may find useful:

#!/bin/bash

RPT_FILE=~/Signing_Report.csv
for i in /Applications/*.app /Applications/Microsoft Office 2011/*.app /Applications/Utilities/*.app
do
        version=`codesign -dv "$i" 2>&1 | grep "^Sealed Resources" | awk '{print $3}'`
        printf ""$i",$version
"
done > $RPT_FILE
2 ACCEPTED SOLUTIONS

jescala
Contributor II

@mm2270: Nice touch with the mdfind command. I had originally done something similar with "find -name *.app" but that kept finding .app files hidden inside of other .app bundles so I left it out. For example this gets identified:

/Applications/Server.app/Contents/Applications/Xsan Admin.app

There may be a cleaner way to do this, but based on your feedback I came up with this:

#!/bin/bash

if [[ `sw_vers -productVersion` != 10.9.* ]]
then
        echo "This command is only intended for use with OS X Mavericks 10.9.x."
fi

RPT_FILE=~/Signing_Report.csv
echo "Application,App Version,Signing Version" > $RPT_FILE

while read i
do
        if [[ $i == *.app/Contents/* ]]
        then
                continue
        fi
        app_version=$(defaults read "$i"/Contents/Info CFBundleShortVersionString 2>/dev/null )
        cs_version=$(codesign -dv "$i" 2>&1 | grep "^Sealed Resources" | awk '{print $3}')
        printf ""$i",$app_version,$cs_version
" >> $RPT_FILE
done < <(mdfind -onlyin /Applications/ 'kMDItemKind == "Application"')

I added a check for the App version as well since that helps me identify which newer versions of apps have been updated with the new version=2 signing.

View solution in original post

nkalister
Valued Contributor

haven't seen any issues. It turns out that the situation was more complex than apple told us- there are many v1 signatures that still work under 10.9.5!
http://indiestack.com/2014/09/accepted-cdhash/

Of the 197 applications that return version=1 on my mac from that script, not a SINGLE ONE gets the warning when launching on 10.9.5.

View solution in original post

17 REPLIES 17

mm2270
Legendary Contributor III

@jescala - Thanks for the heads up with this.
I'm curious though, what is the relevance of the information your script pulls for each app, specifically the rules line?
I'm asking honestly because I'd just like to know (and I don't really know). I'm not all that concerned about this issue, but just in case it does become a problem, I'd like to understand what I'm looking at. :)

jescala
Contributor II

The script creates a CSV report with app names and the code signing version. Anything that says "version=1" will not work on Macs with Gatekeeper enabled unless the user knows and uses the ctrl-click, open workaround. It is not the end of the world but will save a lot of support calls when the change comes around if you can push out updates to apps with "version=2" signatures before the 10.9.5 update goes out.

jescala
Contributor II

Oh, and I should mention that you may need to add other paths in the "for i in" part of the script depending on your particular situation.

mm2270
Legendary Contributor III

Thanks. The "version=1" part was what I wasn't clear on. When I run the script on a Mavericks system it seems to only pull a line labeled as "rules=xx",not a "version=X", so looks like the output on 10.9.x changed. Not even seeing the version information anywhere when doing the codesign command against an app, whether from Apple or any other vendor.

Re: the point on the additional paths, I rewrote the script to grab all apps in the normal /Applications/ path using Spotligh. In case you'd like to use it, or parts of it, here it is, though the point above still applies in that its not really pulling the version info

#!/bin/bash

RPT_FILE=~/Signing_Report.csv

while read app; do
        version=$(codesign -dv "$app" 2>&1 | awk '/Sealed Resources/{print $3}')
        printf ""$app",$version
" >> "$RPT_FILE"
done < <(mdfind -onlyin /Applications/ 'kMDItemKind == "Application"')

JPDyson
Valued Contributor

@mm2270 I got the expected results (Version, not Rule). Perhaps you changed the column in the awk command.

mm2270
Legendary Contributor III

Nope, I first tried the exact same script as @jescala][/url posted and got only the "rules" line in the csv file. I also thought maybe it was the awk column but I tried several different ones. The thing is, if I remove the awk part and just do something like - code sign -dv /Applications/iTunes.app - I don't see a version indicated in the entire output. This is against a 10.9.3 Mac. Not sure why, but it isn't there for me.

Edit: I should note that I get the expected results against a 10.8.5 Mac, so it seems like something in 10.9 that isn't lining up. Again, its not all that big of a deal to me, but just wanted to mention it, in case others who do care about this have the same problem.

jescala
Contributor II

@mm2270: Nice touch with the mdfind command. I had originally done something similar with "find -name *.app" but that kept finding .app files hidden inside of other .app bundles so I left it out. For example this gets identified:

/Applications/Server.app/Contents/Applications/Xsan Admin.app

There may be a cleaner way to do this, but based on your feedback I came up with this:

#!/bin/bash

if [[ `sw_vers -productVersion` != 10.9.* ]]
then
        echo "This command is only intended for use with OS X Mavericks 10.9.x."
fi

RPT_FILE=~/Signing_Report.csv
echo "Application,App Version,Signing Version" > $RPT_FILE

while read i
do
        if [[ $i == *.app/Contents/* ]]
        then
                continue
        fi
        app_version=$(defaults read "$i"/Contents/Info CFBundleShortVersionString 2>/dev/null )
        cs_version=$(codesign -dv "$i" 2>&1 | grep "^Sealed Resources" | awk '{print $3}')
        printf ""$i",$app_version,$cs_version
" >> $RPT_FILE
done < <(mdfind -onlyin /Applications/ 'kMDItemKind == "Application"')

I added a check for the App version as well since that helps me identify which newer versions of apps have been updated with the new version=2 signing.

mm2270
Legendary Contributor III

The code I wrote also pulls all apps, including items like the Xsan Admin.app in your example, so if you don't care about those, you may not want to use the mdfind command.
you can use find with a -maxdepth value so it only goes, say, 2 levels deep.

find /Applications/ -maxdepth 2 -name "*.app"

That still locates all the base MS Office apps and other items in Utilities, etc, but doesn't pull XSan Admin.app as an example.

jescala
Contributor II

@mm2270 The "if [[ $i == *.app/Contents/* ]]" part of my code seems to filter out all those false positives.

mm2270
Legendary Contributor III

Ah, I didn't see that. Yeah, that will work too :)

JPDyson
Valued Contributor

I was also testing in 10.9, so it's strange that you saw something different (though it's 10.9.4).

jescala
Contributor II

@JPDyson and @mm2270: So you're not always getting the "version=1" part of the output for the code sign command? I only have Macs with 10.9.4 and 10.7.5 to test with at the moment. For me it works with 10.9.4, but does not work with 10.7.5 (as expected).

mm2270
Legendary Contributor III

No, it was only me, and its working now for some reason. Not sure what I had wrong before, but I get the version line in the output now. Weird!
Anyway, your code is good. It was just me it looks like. Thanks again for the heads up on this situation!

denmoff
Contributor III

I am curious if anyone has experienced any issues with this now that 10.9.5 has dropped.

nkalister
Valued Contributor

haven't seen any issues. It turns out that the situation was more complex than apple told us- there are many v1 signatures that still work under 10.9.5!
http://indiestack.com/2014/09/accepted-cdhash/

Of the 197 applications that return version=1 on my mac from that script, not a SINGLE ONE gets the warning when launching on 10.9.5.

jescala
Contributor II

@nkalister Thanks for that info! We've only deployed to a handful of test Macs and we were surprised to find that so far we had not seen any issues. I guess that would explain it.

scottb
Honored Contributor

The biggest one for me so far was FontExplorer X Pro. Before the GM dropped, they had issued a fix - 4.2.1. Certainly more complex that we first thought...