It seems quite understandable that there'd be breaking changes between version 0.9 and 1.0, I don't see how you can extrapolate that to "OpenSSL doesn’t offer API compatibility between versions."
I also don't see how the advice to include your own version is any better than shipping two versions.
I think Rentzsch is being somewhere between helpful and sarcastic.
Apple could provide newer libssl dylibs and programmers should link against specific versions. You could argue the only mistake in this instance is the existence of the generic libssl.dylib symlink which will need to point to 0.9.8 in perpetuity.
Exactly why Apple have given up on OpenSSL is anyone's guess (since Apple aren't saying -- hence Rentzsch's post). You could insert a conspiracy theory but my guess is that they can't be bothered curating and patching another OpenSSL library version since they themselves only ever use libcrypto.
Apple could -- and do -- security patch libssl.0.9.8.dylib. So while you will never go from 0.9.8 to 1.0.1 automatically, you could automatically go from 0.9.8r to 0.9.8s automatically.
I believe it may of had to do with compliance with some US Government standard? Their own stack complies but they are unwilling and/or unable to do the same for OpenSSL.
I recall there being a presentation from last years WWDC about this change...
Extrapolate? If there were breaking changes between 0.9 and 1.0, that is failing to offer API compatibility between versions. It doesn't matter whether it's understandable or not, they need X, the project provided not-X, and so it's not what they need. Apple shipped OpenSSL, then subsequently had problems with binary compatibility due to breaking changes, so now they're choosing a different approach.
• Symmetric Encryption: AES, DES, 3DES, CAST, RC4, RC2, and Blowfish. (The algorithm selection is poorly documented in the man pages, I'm reading source here.)
It has an API that would not surprise anyone who has used a similar library.
It's only deprecated in the sense that Apple are no longer going to supply it. You can either switch to CommonCrypto (if it's appropriate) or bring your own OpenSSL.
Seriously, considering that 0.9.8 was released in 2005. During the last 7 years are you telling me openssl is the only "unixy" library to have a new backwards incompatible version come out? And by the way, they are still providing updates to 0.9.8. It's still the default version in debian stable.
So to recap: 0.9.8 is by no means unsupported. The saints over at the openssl group are continuing to provide updates to this 7 year old library so that people like Apple can continue providing seamless security updates to users who have linked against 0.9.8.
Apple is welcome to do what they like (and it seems like they're offering alternatives that are at least equivalent, and possibly superior) but a "major release" has incompatible changes to APIs by definition.
Mac OS X has gone through a large number of major releases without making binary incompatible changes to APIs. That may be one definition of "major release", but it's certainly not universal. In any case, I don't understand this discussion centered around whether OpenSSL is justified in doing this or that. It doesn't matter! Apple needs binary compatibility, OpenSSL does not provide it, Apple doesn't expose OpenSSl. That's it. The reasons why OpenSSL doesn't provide it, whether they're right or wrong or just sideways, simply do not matter.
Besides, Apple's major OS releases are executed like a major version number bump regardless of how others outside the company do things. These bumps include deprecation markers and warnings for APIs with planned retirement. There's no technical reason to remove deprecated APIs (keeping them around forever) to support older apps.
Why does enhancement necessarily require breaking changes in the APIs? Apple has a huge amount of experience in building C-level APIs that support far-reaching forward compatibility.
Open source libraries like OpenSSL tend not to bother, because their model is that you recompile stuff whenever they make binary breaking changes. And there's nothing wrong with that, it's just not how Apple operates. But it's not something inherent in the concept of libraries.
Because the OpenSSL 0.9 APIs have some serious issues, and there are quirks in BIO destruction, etc, that couldn't be fixed without breaking a lot of code. That's why they maintain two trees; 0.9.8 for compatability, and encourage people to use the 1.0 tree, which not only has some new features, but also some important API fixes and improvements.
It's important to note that you can in fact have both openssl library branches on your system and that isn't a problem. It's a mis-statement to refer to these things as breaking changes, as your 0.9.8 linked code is not going to break anytime soon.
I've found that the EVP library (provided with OpenSSL) to be good for implementing basic cryptographic functionalities. It provides a decent layer of abstraction that's portable across different versions of OpenSSL.
I also don't see how the advice to include your own version is any better than shipping two versions.