About Me

I'm a software developer running my own business creating, supporting and selling Mac, iOS and Windows software that helps educators stay organized and work efficiently.

Previosuly I was a physics and chemistry teacher, president of my local teacher's union and served on the Board of Directors for the Oregon Education Association.

I'm currently enjoying 300+ days of sun each year in New Mexico.

Search
Navigation

Code-Signing, OS X 10.7.5 and OSStatus error -67061

I recently sent out Planbook 4.0.7 for Mac to the members of the Planbook mailing list and almost instantly received a surprising report about 4.0.7 crashing on launch. Thanks to a helpful user who sent in a bug report that contained the following

xpchelper reply message validation: code signature invalid
The code signature is not valid: The operation couldn’t be completed. 
(OSStatus error -67061.)

I was able to track the bug down to an issue with the code-signing feature built into the Mac development tools. At best, code-signing allows users to confidently download applications knowing that the program they download matches what the developer published (i.e., no viruses or hacks were inserted into the program before you downloaded it).

Unfortunately, code-signing appears to be broken (at least in some cases) on OS X 10.7.5 (the latest update to Lion). The problem can be fixed on the developer's end by turning off time-stamping when code-signing the application. What a strange bug in OS X. I guess I'll add an extra code-signing step to my application deployment checklist to work around this bug.

For future reference, code-signing after an archive is accomplished using the terminal:

export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"

codesign -fs 'Developer ID Application' --prefix 'com.yourcompany' --preserve-metadata=i,e,res,req --timestamp=none YourApp.app/

Core Data, SQLite and Apple's Sandbox

A new feature coming to Planbook (soon!) requires exporting a Mac data file to an SQLite data file. This should be an easy task, given that Planbook uses Core Data (and Core Data natively supports using SQLite as a persistent data store). Unfortuntaley, Apple's Sandboxing broke the use of SQLite with Core Data because saving to an SQLite file requires the creation of a secondary file that stores information about how the data was placed into the SQLite file. Apple's Sandbox prevents the creation of this secondary file (because the User can not explicitly allow the creation of this file).

On OS X 10.8.2, here's the specific error message I encountered when trying to write an SQLite file to a user-specified location:

coreData: error: (21) I/O error for database

There are a supposedly a number of ways to work around this, including turning off the journaling feature of SQLite. I tested this fix for a bit but couldn't generate an SQLite file in this manner.

After thinking for a bit, I came up with another work-around. Because I'm exporting data from my app (and not using the SQLite store as a normal data file that will be continually read from and written to), I simply generate the SQLite data file inside my applicaiton's Sandbox folders and then copy the file to location specified by the user. I don't love this solution, because it's got an extra point of failure, but I don't see another solution to this problem that's less of a hack.

I probably should have thought of this solution a bit more quickly, but I'll chalk this up to another hour or two trying to work around problems in Apple's Sandbox.

FTP in an Objective-C/Cocoa Mac app

Planbook has long had the ability to generate static HTML files for your lesson plans and transfer those files via FTP for public access on the Web. Originally, I wrote my own FTP transfer code, but then I stumbled upon ConnectionKit, an open source FTP/SFTP/WebDAV framework. I've used ConnectionKit for years without incident.

But now that I'm working on making Planbook a modern, 64-bit app, I need a new solution. While there appears to be active ConnectionKit development, it hasn't become a fully 64-bit framework and the documentation is basically non-existent. Getting it to work would require either continuing to distribute Planbook as a 32-bit app (not ideal) or mucking through the ConnectionKit code to generate and use a 64-bit version of the framework. After 2 days of working with ConnectionKit, I made some progress, but it didn't seem likely to yield a viable solution.

Fortunately, I discovered Apple's relatively simple FTP client sample code. It's iOS focused, but the core networking code is all CFNetwork based and can easily be used with Mac OS. After a couple more hours of work, I've got FTP integrated back into Planbook with no outside dependencies.

DD-WRT and Home Network Speeds

I noticed that Comcast was offering a cheap deal ($29.99/month) for their fastest home internet package. We upgraded (which actually lowered our bill), but I didn't really see a noticeable impact on our connection. I've always thought our home wireless network was a little slow (even transferring files between computers or the Apple TV) so I did some digging.

I use a Netgear Dual Band Wireless N router (the WNDR3700 v2, to be exact). I've also flashed the firmware and am running DD-WRT on the router for extra configurability. It was easy to install, following the provided directions. I noticed that my iMac was connecting to the router at a max of 54mbps, far slower than the 300mbps the router should provide.

Based on a random forum article, I suspected that our connection issues might have something to do with the encryption algorithms we use for the WiFi networks our router manages. It was a quick fix to adjust the router to use AES, rather than TKIP, to encrypt our signal. I'm not sure why DD-WRT defaults to TKIP, but making the change instantly boosted my iMac to a 300 mbps connection, and increased my speedtest results results by 50% (up and down). Comcast is giving us a pretty good connection for our $30/month.

Previously we'd get an even 20 up and down.

Smoky Albuquerque Sunrise

Smoke from the 70,000+ acre Whitewater Baldy Complex Fire has filtered into Albuquerque, making for a nice sunrise and poor air quality.