As mentioned in the Alpha/16 update that we just posted, we’ve started signing the code for SigmaTerm. Here are some gotchas for doing this using XCode that we’ve noted, as well as some tips for an inexpensive code signing certificate.
XCode Notes
Copy files considered harmful
Watch the freaking “Copy files”-type build steps. The default settings for an executable target will strip debug symbols from the copied files. Anything signed before this point (like executables or frameworks from another project) will be rendered invalid, and will need signed again. Solve this by either unchecking “Strip Debug Symbols During Copy” in the properties for your target, or pre-stripping your files before signing them in their original project.
XCode’s signing settings
XCode has some tempting settings for targets relating to code signing. This includes some simple drop-downs for signing your app or framework for each build. This works for simple applications - a straight app bundle. But doesn’t work for frameworks at all. Frameworks must be signed using their individual versions. From the command line you’d sign Foo.Framework/Versions/A instead of Foo.Framework. XCode does the latter, and screws everything up. Use a Run Script build step to run codesign manually with something like this:
ID="Debug"
if [[ ${CONFIGURATION} == "Release" ]]
then
ID=”ETrow”
fi
codesign -f -s ${ID} “${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/Versions/A”
When to sign
Apple recommends not signing your apps until you’re ready to release. That way, you can be sure that debug versions or unfinished software doesn’t get out there with your signature on it. It’s a nice sentiment, but in practice, if I have to hit one more freaking “Allow” button on a keychain dialog, I will murder someone.
The solution, of course, is to use two identities. One is a self-signed “Debug” identity, and one your final identity. Notice above in the Run Script example that if we’re building a release version, we sign with ETrow’s identity. Anything else gets the Debug identity. Apple has a quick writeup for creating your own self-signed certificate.
The self-signed versions of your app won’t validate on anyone else’s machine except yours, and it keeps those annoying dialogs down to a minimum during development. The best of both worlds.
Where to get your certificate
Have you checked the prices for code-signing certificates lately? If you’re a small development house, $299+ a year might seem like a lot of cash to lay out for a four kilobyte text file. Fortunately, there are cheaper options.
The best one I found was Comodo - direct from their web site, they offer a $179/year version. But there are a pile of resellers around that give discounts. Of these, the venerable Tucows offers those who sign up as developers a $75 version of the Comodo certificate that works great. If you’re a certificate snob, Tucows also offers a discounted $160 Thawte certificate.
Don’t be put off by Comodo’s statements about browsers and what their certificate can be used for (Sign your .exe files!) The signup works fine in Safari Beta 4 (and probably older versions) and the resulting certificate works well. One note about Thawte - last time I used them to get a code signing certificate, it forced me to use Internet Explorer on a Windows machine. Ick.
Remember, you’ll need some documentation when signing up with any of the code signing providers. Comodo will work with small shops and individuals, but be prepared with phone bills, incorporation papers, etc. Thawte is much less accommodating to individuals.
Technorati Tags: apple, certificate, os x, code signing, sigmaterm, terminal emulation, terminal emulator