Code Signing Will Kill Me Yet

This is one of those I-spent-long-enough-stumped-on-this-issue-I-should-write-it-up-for-future-generations posts.

I wrote a little app at work (which I’ll talk about in a future post), and I was having a strange code signing issue. The app would sign just fine:

$ spctl --assess -v Orwell.app
Orwell.app: accepted
source=Developer ID

But then if I zipped it up and sent it to someone, when they unzipped it, OS X would tell them that it was damaged and should be thrown away:

Blech

Sure enough, if I zip and unzip the app, and verify the code signing again, I get:

$ spctl --assess -v Orwell.app
Orwell.app: a sealed resource is missing or invalid

After much hair-pulling, I found Technical Note TN2318: Troubleshooting Failed Signature Verification, which says:

The file prefixed with “._” is problematic and a was the result of copying certain Mac OS X files to a non-HFS+ formatted disk. These files are referred to as Dot files, Apple Double files, or resource forks. They are invisible to Finder but can be removed using the dot_clean utility.

Sure enough:

$ find Orwell.app -name "._*"
Orwell.app/Contents/Resources/app/node_modules/applescript/._package.json
Orwell.app/Contents/Resources/app/node_modules/applescript/lib/._applescript.js
Orwell.app/Contents/Resources/app/node_modules/applescript/samples/._execString.js
$ dot_clean Orwell.app
$ find Orwell.app -name "._*"

Running dot_clean before I signed the app fixed the issue.

(Orwell is an Electron app, hence the node_modules dir, in case you were wondering.)

Tweet