Snafu: Code Signing with Background Tools

Matt Patenaude

Bowtie 1.3 launched on the Mac App Store to much success, but after a couple of weeks, I started receiving some one-off support emails from users who were being asked to "Allow" network access every time Bowtie started up. Essentially, these users had the OS X Firewall enabled, and the background "Bowtie Butler" process was reporting that it had an invalid code signature, meaning it was subjected to much harsher security restrictions.

Not using the firewall myself, I had never noticed this, and just assumed that, since my app was code signed without a problem, the Butler tool was as well. Turns out, all was not well.

The Gotcha

When you use one of Xcode's "Copy Files" build phases to copy executables into your Resources (or MacOS or what have you) directory, by default, it strips out debugging symbols. That means if that executable had already been signed, its signature is now invalid. Great.

The way to get around this is to Get Info on the "parent" target (ie, in the case of Bowtie, the Bowtie.app one), and in your Release configuration (or all of them if you like), make sure to uncheck "Strip Debug Symbols During Copy".

Screenshot of the Xcode Target Configuration panel.

The next time I built, all code signatures verified without a problem (checked with the codesign -v <pid> command).

To that end, Bowtie 1.3.1 is on its way to the App Store to fix that problem some users may have experienced. :)