Oddly, iOS doesn’t provide any OpenSSL implementation at all — If you want to do anything with crypto (like checking signatures, checksumming, etc.), you have to build in the library yourself.
I came across a great XCode project wrapper for OpenSSL yesterday, by Stephen Lombardo. This is an XCode project file that contains a target to build OpenSSL from source, and works with both Mac and iOS projects. I made some modifications to it, in order to make it work by just dropping in the OpenSSL source tarball, without having to dirty up your source tree with the extracted OpenSSL distribution.
Here’s how to use it:
- Download the OpenSSL source.
- Put the downloaded OpenSSL source tar.gz into the same folder
as openssl.xcodeproj (I put it in
Library/opensslwithin my project tree). - Drag the openssl.xcodeproj file into your main project tree in XCode.
- Right-click on your project target, and add openssl.xcodeproj under “Direct Dependencies” on the General tab.
On the Build tab for your project’s target, find the “Header Search Paths” option, and add the path:
$(SRCROOT)/Library/openssl/build/openssl.build/openssl/include(Assuming you’ve put openssl.xcodeproj at the path
Library/openssl— adjust as necessary).- Expand your target’s “Link Binary With Libraries” build stage, and drag libcrypto.a from the openssl.xcodeproj group.
Then, you can just import and use as normal (#import <openssl/dsa.h>, etc).
Add us on Facebook!
Fixing Xcode 4′s symbolicate utility to get comprehensible crash logs
‘symbolicatecrash’ is the Developer Tools utility which replaces all those meaningless addresses from crash logs with actual symbol names and source code references. It lives at some obscure folder within
/Developer– usefindto dig it up and symlink it into/usr/local/binif you wanna use it conveniently from the command line.Anyway, after plenty of frustration, I noticed some chatter about the damn thing being busted in Xcode 4. Figures!
There’s an alternate third party version on GitHub, but this didn’t really help me – I still got inscrutable errors, so I took a look at the original.
The version that comes with Xcode 4 appears to have some problems distinguishing, say, an iPhone Simulator build of the app from a native build sitting in the Archives folder. I’d just see an error about otool and some binary living in the iPhone Simulator folder.
Digging into the errant symbolicatecrash source, I noticed that the code that finds the executable path tests each candidate using otool, but doesn’t seem to be able to comprehend the output from otool caused by running it on the wrong architecture.
So, replacing the rather unhelpful ‘die’ statement on line 323:
die "Can't understand the output from otool ($TEST_uuid -> '$otool -arch $arch -l $path')";With a “No, it ain’t this executable” response:
return 0;…solves the problem immediately. Now I can drag crash logs straight into the Organizer in Xcode, and it’ll symbolicate correctly.