Now your app doesn’t get security + capability updates for free. For example: /usr/lib/libcrypto.0.9.8.dylib. (Notice we’re still shipping v0.9.8r when v1.0.1c is the latest.)Īpps link to a specific version of libcrypto. In practice we’d break shipping apps since the APIs are different.
#Iwrite apple free#
In theory we should be able to always point that to the latest version of libcrypto.dylib and apps get free security + capability updates. We’d love to ship updated versions of OpenSSL, but there’s only two feasible routes, both of which are seriously problematic:Īpps link to /usr/lib/libcrypto.dylib symlink. The crux of the problem is OpenSSL doesn’t offer API compatibility between versions. We know that’s a pain, but this project should help you out.Īdd -isystem "$(SRCROOT)/openssl-1.0.1c/include" to OTHER_C_FLAGS to pick up your project’s local OpenSSL headers instead of the system’s headers (which are outdated and throb with deprecation attributes). You should stop using the system’s supplied libcrypto.dylib, build your own and link it into your app. It’s called COMMON_DIGEST_FOR_OPENSSL and lives in CommonDigest.h.Īpps That Need OpenSSL Should Include Their Own Copy. CommonCrypto provides a thin OpenSSL compatibility shim for common cryptographic message digests. It solves OpenSSL’s issues described below in the Backgrounder section.Ĭode That Uses OpenSSL Just for Hashing Should Switch to CommonCrypto. SecTransform is cool: it’s high-level, rather declarative, fast and even leverages GCD. (We learned our lesson and didn’t repeat the mistake with iOS.) Long story short: we screwed up when we included OpenSSL ( libcrypto) in OS X in the first place.
0 kommentar(er)
