1

We have a crossplatform app using CMake and we have been linking to precompiled OpenSSL binaries. But we would like to link to Android and iOS's own OpenSSL.

  1. How do we do it in CMake?
  2. We do it primarily to avoid using a binary not compatible with OS version. Is it a valid or a typical concern?
M W
  • 1,269
  • 5
  • 21
  • 31
  • `How do we do it in CMake?` - just choose right libraries for link. If you use find_package(), give it a hint about location of the libraries. – Tsyvarev Apr 19 '16 at 20:31
  • Though you have accepted an answer, you should wait to get an answer to your question about linking to your versions of the library with Cmake. – jww Apr 21 '16 at 00:18
  • ***`We would like to link to Android and iOS's own OpenSSL...`*** - this is often a bad idea because the OEM often abandons their software after release. You would have a better security posture if you built against your own, up-to-date OpenSSL, and pushed it with your app. Then, your app will always be up-to-date, regardless of what the OEM does. You will have the same problem with Apple and CommonCrypto. Apple abandons their software, too. Its often better to move to maintained libraries, like OpenSSL, libxml2, etc. – jww Apr 21 '16 at 00:22
  • @jww Thanks for your advice, and it is a valid observation. But I cannot agree with you. The answer is very thorough, does touch on the how (enough for me) and more importantly it looks beyond the literal questions and tell me exactly what I want to know. But for clarity, I did update the title. – M W Apr 21 '16 at 15:54

1 Answers1

2

If you are wanting to link to Apple-provided OpenSSL libraries, you may want to rethink that strategy. Apple have the following text in their cryptographic services guide (emphasis mine):

Although OpenSSL is commonly used in the open source community, OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged.

If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app. This use of OpenSSL is possible on both OS X and iOS. However, unless you are trying to maintain source compatibility with an existing open source project, you should generally use a different API.

Also see answers here and here. So for iOS at least, you will have to build your own OpenSSL anyway. One could argue that you probably want to do that for your Android builds too for consistency and for similar reasons as those in the extract above from Apple.

As @Tsyvarev said in his comment on your question, use find_package() with appropriate hints to point your build at the OpenSSL you want to use. Your question indicates you already use your own pre-built OpenSSL, so presumably you are in control of where it is located and using find_package() would be a nice platform independent way to handle the different library suffixes, etc. Recent versions of CMake will also give you import targets which will carry with them include path dependencies, so they will be easier for your code to use (just link to them and get the header search path for OpenSSL added for free). Have a read of the CMake docs for the FindOpenSSL module for extra details.

Community
  • 1
  • 1
Craig Scott
  • 9,238
  • 5
  • 56
  • 85
  • Seems like we should try common crypto on iOS. We are using Darwin SSL already; we just need the crypto component. – M W Apr 20 '16 at 21:05