BoringSSL inclusion in iOS 11

Is there any way to prevent the loading of the libboringssl.dylib?


We are using libssl.dylib for some specific functions. libboringssl is actually crashing during ssl_create_cipher_list - which led us on to the fact that iOS 11 is now using BoringSSL...

Accepted Reply

So after wasting most of a day on this - what ended up fixing was renaming the @rpath's within the local libssl and libcrypto dylibs.


Does not explain 1) Why apple is including "do not use this" Google libraries 2) it is crashing when setting TLS ciphers

Replies

Bugreport.apple.com

So after wasting most of a day on this - what ended up fixing was renaming the @rpath's within the local libssl and libcrypto dylibs.


Does not explain 1) Why apple is including "do not use this" Google libraries 2) it is crashing when setting TLS ciphers

1) Why apple is including "do not use this" Google libraries

I do not understand this question. Please clarify what you mean.

2) it is crashing when setting TLS ciphers

Because OpenSSL (and hence BoringSSL) were not architected to support binary compatibility, so if you use version X’s headers to call version Y you get into trouble. This is exactly the reason we deprecated the OpenSSL dylib that was built in to macOS back in the day.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Google specifically says (Not discounting Apple could have a different relationship) that BoringSSL shouldn't be used by 3rd parties.


Just curious Apple is using BoringSSL within iOS, that is all.

Google specifically says (Not discounting Apple could have a different relationship) that BoringSSL shouldn't be used by 3rd parties.

Yeah, that’s way outside of my purview and so you’ll get a big “No comment” from me (-:

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

@eskimo,

[It's been a while, I know. I hope you'll still get a notification about this message, just for closure]


Your response at https://twitter.com/steipete/status/979725476364242944?lang=en says more than your reply here. Just a bit more, but enough:


It’s been an implementation detail under Secure Transport since iOS 11. Secure Transport is still the lowest level API though


The reason Google don't recommend others to use BoringSSL is "Doing so is likely to be frustrating because there are no guarantees of API or ABI stability". So it's just fine if Apple decide to take a given version of the library and use it in iOS.