Category: iOS

Accessing the keychain in OS X from the command line

There is a very useful utility called security(1) in OS X, which lets you manipulate your keychain from the command line. You can easily im- and export keys and certificates using this. This is especially useful for AppStore developers, who code on multiple Macs. Having the signing keys in sync is kind of a challenging solution, if you don’t use keychain syncing via MobileMe. For example you can import a key like this into your login keychain:

$ security list-keychains
   "/Users/yourguy/Library/Keychains/login.keychain"
   "/Library/Keychains/System.keychain"
$ security import -k /Users/yourguy/Library/Keychains/login.keychain somekey.pem
1 key imported.

Hope this helps.

Note to self: codesigning for OS X and iOS on the command line

As a reminder for myself, here is how you can codesign an OS X application for the AppStore on the command line:

codesign -f -s "3rd Party Mac Developer Application: Your Company" -v YourApp.app
productbuild --component YourApp.app /Applications --sign "3rd Party Mac Developer Installer: Your Company" YourApp.pkg

There is a lot more to do, of course, like having the correct bundle ID set, but this speeds up codesigning, if you do not use XCode to build your application.

For iOS it is pretty similar, except you don’t need the productbuild:

codesign -f -s "iPhone Distribution: Your Company" -v YourApp.app

Alignment of double values on ARM architectures

Consider the following code:

class C {
...
uint8_t *data;
size_t size;
...

void writeDouble(double v)
{
    ...
    reinterpret_cast<double*>(this->data)[this->size] = v;
    this->size += sizeof(double);
    ...
}

};

Looks harmless enough, doesn’t it? But here is the problem: It’s not necessarily portable or well behaving code. After debugging for about three hours, I found out something interesting. Namely that on ARM platforms, such as the iPhone, double values on the stack need to be stored at 8 byte aligned memory addresses. This was some existing code I was using, so it took me a while to get to this function and to its problem. Single precision float values have no such restriction, by the way. There are two workarounds in the above case. 1) Write a small for-loop that casts the double value to a uint8_t * and copy the double value byte-wise, or 2) use malloc to copy the value. I did the for-loop, since I thought that maybe the malloc call has too much overhead. I guess you could also cast the double to a uint32_t * pointing to two 32 bit words. Anyway, take care when doing such drastic casts. Some platforms might want alignment for some datatypes!