What about this post?
http://www.theregister.co.uk/2014/04/22/apple_ios_7_1_1_os_x_security_updates/
This ain't /. (or is it going that way?_
Apple has squashed a significant security bug in its SSL engine for iOS and OS X as part of a slew of patches for iThings and Macs. The so-called "triple handshake" flaw quietly emerged yesterday amid panic over OpenSSL's Heartbleed vulnerability, and soon after the embarrassing "goto fail" blunder in iOS and OS X. Apple's " …
That's an interesting link, thanks. Highlights for those that can't be bothered to read it:
"The problem is, as I said above, that OpenSSL does not have a stable ABI ... if you made an OpenSSL dylib and people expected it to work, uh, you know, with dynamic linking, their code will break. ... We talked to the OpenSSL people and noted that we really needed to be able to be able to make and ship dylibs, and asked if there was anything we could do to help. ... OpenSSL rebuffed Apple and I gathered that the rebuff was actually insulting. It probably wasn't literally, "why don't you go back and make lickable buttons" but that would have given a similar result. One thing I know that OpenSSL said was that the unstable ABI was a feature, not a bug, and that anyone who really cares about security should statically link OpenSSL ...
Thus, OpenSSL is intrinsically not supportable in system that likes dylibs. We had to fix that underlying issue. So what fix? ... [we chose] what you see now. OS X still ships OpenSSL 0.9.8y (or at least that's the version on my laptop), and the entire system is as it was in 2011.
I think that someday, someone's got to give OpenSSL the decent burial. That OS X ships with 2011 OpenSSL command line tools and dylibs is a bug. ...
Heartbleed isn't a crypto problem. It's a software engineering problem. ... Apple's decision to chuck OpenSSL was also a software engineering decision, not a crypto decision."
Thus, OpenSSL is intrinsically not supportable in system that likes dylibs
Unless you statically link it into a dynamic library that does provide a stable ABI, which is fairly trivial. That's what we do, and it's worked just fine with OpenSSL 0.9.8, 1.0.1c, and 1.0.1g.
This also lets you provide APIs for higher-level functionality that OpenSSL doesn't already compose (like PKCS#12 operations), hide symbols for functions you don't want callers to use, implement cross-cutting concerns like tracing, etc. You know, like real software developers might do.
There are a number of reasons to dislike OpenSSL, but this one is rather minor.