Code signing is a technology for associating a cryptographically secure signature with your application’s executable code. This signature makes it possible for the operating system or other services to make confident assumptions of authenticity based on the unique signature which you’ve supplied.

Thus, code signing is a technology which is rather useless in itself, but which can be utilized by other services to achieve specific goals. Starting with Mac OS X 10.5, Apple built some features into the operating system which take advantage of code signing, including some features which make accessing secure items from the keychain less of a nuisance.

In particular, consider the scenario in which an application asks permission from the user to access items in the keychain. Once the user gives permission to “always allow,” the application can thereafter obtain a secret value from the keychain without user intervention. This is very handy for internet passwords, etc. But once the application changes, e.g. a new version comes out, the user must be asked again to permit the access. This is to ensure that malicious code hasn’t been snuck into the application.

But with code signing, the users permission can be expanded to cover any release of the application that was signed by the same certificate. The idea is that if users approve one version of an application, then they’ll likely approve the next version, as long as they are guaranteed it came from the same developer.

I have so far not signed any of my publicly released applications. I may do so soon, because these conveniences would remove one more tedious task for users who are updating to the newest versions of my applications.

But the user who has it worst of all is me myself, as I’m constantly revising the application, leading the system to request new approvals every time my changed application accesses the keychain. To get around these constant requests, I finally decided to at take advantage of code signing during the development phase. What does that mean? It means I’m committing to signing my own code for my own internal purposes, but not yet committing to signing publicly shipped products.

From Zero To Code Signed In 300 Seconds

With Xcode 3.0, code signing is easy, but takes a little work to set up. Since I just went through the somewhat tedious task myself, I thought I’d share with you how it’s done easily and predictably:

1. Establish a self-signing certificate. Apple offers simple instructions for how to do this with the Apple-provided Keychain Access utility. When you create the certificate, you’ll be asked to give it a name. Name it whatever you like, for instance “My Cert”. The certificate is stored in your keychain, where it can be easily referenced by name.
2. Add a custom build phase to Xcode. Xcode will not automatically sign your code, but it’s easy enough to add a build phase that does. Select your target in Xcode and choose “Project -> New Build Phase -> New Run Script Build Phase” from the main menu. Paste in the following script:

   if [[ ${CONFIGURATION} == "Debug" ]]
   then
   	# -f means force to re-sign even if already signed
   	codesign -f -s "My Cert" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/"
   fi
   

   Observe that the “My Cert” text can obviously be changed to whatever you ended up naming your certificate. Also notice that because of my hesitation to ship a code signed application yet, I am restricting the action to only the Debug build configuration. If you’re ready to go public, just remove the test and the code signing will happen for all build configurations.

3. There’s no step 3! Enjoy.

Constantly approving those keychain approval dialogs is one of the things that I just fell into the habit of tediously doing. Thanks to Apple’s code signing efforts in 10.5, there’s no longer any reason for me to do that. Hopefully if you use the keychain in your own development products, you’ll find this productivity upgrade useful as well.

At this year’s Macworld conference, the guys at Rogue Amoeba decided to do what many trade show exhibitors do: give away a free demo CD to interested attendees. But recognizing the conventional drawback of these demos, that they are obsolete from almost the minute the disc is burned, they invested in developing a clever application that runs from the disc, and conveniently presents the latest copies of all of their software to the user. If what’s on the disc is still fresh, the user runs it. Otherwise, the latest version is downloaded from the web and that’s what the user sees instead.

I spoke to them about their solution at the time, and was impressed by it. It certainly seemed like a good way to avoid turning those thousands of plastic discs into guaranteed landfill fodder. But what’s even cooler is that they’ve now decided to share the technology so that other companies who are interested can pull of the same feat with a minimum of work:

Announcing LiveDiscKit

It’s also worth reading to near the end of the article, where they confess that even with the clever technology in place, the discs did not turn out to be all that effective as marketing tools:

Of the 5,000 discs we gave out, 5.8% were ever used. That may seem a bit low, but it gets quite depressing when converted to an absolute count: 288. Out of 5000 CDs given out, no more than 300 were used – perhaps giving away CDs isn’t the best idea after all

Well, you can’t win them all! On the bright side, I don’t think they would have been able to gather this information without putting in the effort to make the discs smart enough to “check for updates.” It was a valiant effort, and a very cool idea that other companies might still find useful.

The WordPress developers have decided that, starting with WordPress 2.6, access to the XMLRPC and AtomPub-based remote publishing interfaces will be disabled by default. Users who wish to use a remote client such as MarsEdit will have to go out of their way to enable the required functionality in their blog’s settings.

There are good arguments for this, at least on the face of things. They can be packed into a nutshell: it may reduce the security risks of having these access points opened by default.

But in my opinion, there are also good arguments to be made for rejecting the change as a damaging and misguided solution.

First, and obviously near to my heart, is the fact that this marginalizes remote clients. For users who would find value in a remote client, this decision will put one more roadblock in their way. Historically, the remote editor interface is already compromised such that remote editors do not have access to all the same functionality as the web interface. With this change in place, things get even worse. While a screen-scraping application will easily log in and authenticate a fragile WordPress session via the web interface, the well-behaved API clients will be refused access by default. All in the name of improving security.

Second, and probably most important, is that this is not a fundamental security improvement. Consider a bank with two sets of automated cash machines: one for drive-through cars, and one for walk-up pedestrians. Two vastly different sets of customers are being served securely by different interfaces, yet the transactions are secure because they ultimately travel through the same bottlenecked safeguard. A fundamental design consideration on the part of the bank is that these two classes of customer are equally important, and each deserves unfettered access.

WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.

Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!

A Real Solution

If I’m so smart, what should WordPress be doing instead? A real security improvement would be bottlenecking all access to the blog’s vital authorized content, and making sure that the remote APIs and the web interface all go through the same interface.

In my opinion, an entire class of problems with WordPress (and other blogging systems) stems from this interface bifurcation. Establishing a single interface to WordPress would be comparable to the “pin code + card” interface at your bank. You pass through it by car, on foot, and even at the counter when they ask you to swipe before doing any transaction.

If you’ve only got one “real API” that touches the critically important data, then you’ve only got one door to secure. Furthermore, when all views into the blog are required to share the same API, suddenly none of them is deprived of functionality that the other has.

Imagine if the API that the web interface uses to access all features of a blog could be just as easily employed by MarsEdit or any other application you authorized. The end result would be lots less work “playing catch up” for the XMLRPC and Atom developers, and more time focusing on innovative and cool features for all blog users.

If this sounds like a pipe dream, it’s worth pointing out that one very popular web service is already employing this strategy, and it works brilliantly. Flickr, Yahoo’s incredibly popular photo sharing site, is built on the very same APIs it makes available to clients. This results in some truly incredible Flickr-enabled applications and web services. And you don’t see any sign of Flickr disabling access to their API, because there’s too much at stake.

If your web service only provides one, first-class API through which all access flows, then you’ve only got one point to secure, you’re likely to have feature parity across interfaces, and the risk of marginalizing one interface is dramatically decreased.

I’ve just updated my Black Ink crossword solving app to version 1.1, bringing a dramatically improved printout quality, and a host of other small improvements:

Black Ink 1.1

• Dramatically improved puzzle printing quality
• Improved highlighting of active clue in clue list
• Fix for crashing scenario when migrating preferences to a new Mac
• Improved reliability of puzzle downloads
• Fix some bugs with timer restarting after pausing
• Updated default puzzle sources
  • New: Boston Globe Sunday
  • New: Little Rock Daily Record
  • Removed: Washington Post Sunday

It turns out printing is one of those features you can really start to obsess on. I am very happy with the improvements that have been made for 1.1, but just getting under the hood and having my hands dirty has taught me so much about how it can be improved even more.

Exactly what has gotten better with printing? For starters, the application does a better job of remembering your printing options (selectable from the Page Setup dialog). But the real joy is in the improved quality of the paper (or PDF) printouts you generate. The output is now much sharper and closer to “typesetting quality.” Finally, the layout of the clues list has been revised to offer more readable, flowing text that fills the width of the page more naturally.

For future updates, I’m looking forward to offering further refinements. At the top of my list is a preference for “handedness,” so you can print the puzzle grid at the appropriate side of the clues for your preferred solving hand. I also hope to increase the flexibility of clue and grid sizing, so that users with better or worse vision can get the most out of the printout feature.

Enjoy, and please let me know what you think!

Update: Round version numbers are boring, right? If you already downloaded 1.1 be sure to grab the 1.1.1 update which fixes a really annoying issue with the very printing improvements I’ve highlighted here. In the hubbub of getting these new features in, I neglected to notice that for users who haven’t been incrementally using my private beta builds, the printing options would have been set to unfortunate default settings, which caused a nearly blank printout page :)

Many thanks to David Brown for spotting this and letting me know in the comments below.