Wherein I Write Apple’s Technote About OpenSSL on OS X(rentzsch.tumblr.com)
rentzsch.tumblr.com
Wherein I Write Apple’s Technote About OpenSSL on OS X
http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-technote-about-openssl-on-os-x
28 comments
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.
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...
Have you ever used OpenSSL? It is a total mess. For a popular project, its code is unreadable. I don't know how they maintain it.
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.
You won't find any Apple technote on the subject because the use of OpenSSL is deprecated on iOS and OS X from their point of view.
Deprecated in favor of what? This post talks about a compatibility layer between app source code and OpenSSL.
Common Crypto contains functions for
• Hashing: MD5, SHA1, SHA2
• HMAC (hash based message authentication) http://en.wikipedia.org/wiki/Hash-based_message_authenticati...
• PBKDF2 (password to key) http://en.wikipedia.org/wiki/PBKDF2
• 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 is open source, APSL 2.0. You can read it here: http://www.opensource.apple.com/source/CommonCrypto/
• Hashing: MD5, SHA1, SHA2
• HMAC (hash based message authentication) http://en.wikipedia.org/wiki/Hash-based_message_authenticati...
• PBKDF2 (password to key) http://en.wikipedia.org/wiki/PBKDF2
• 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 is open source, APSL 2.0. You can read it here: http://www.opensource.apple.com/source/CommonCrypto/
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.
See WWDC 2011 session 212 slide 50.
This is so undeservedly harsh.
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.
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.
http://www.openssl.org/news/changelog.html
http://www.openssl.org/
I'm looking at upstream tracker [1], and I can see a number of changes in the later releases, but is the API really that unstable?
What parts of the API in particular are that bad?
1. http://upstream-tracker.org/versions/openssl.html
What parts of the API in particular are that bad?
1. http://upstream-tracker.org/versions/openssl.html
I see 27 symbols removed in version 1.0.0. That is 27 symbols that cannot be found by the dynamic linker if an older app binary requires them.
That's a major version change. You expect API compatibility typically with patch-level and minor releases.
Apple needs API compatibility across major versions too.
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.
OS X hasn't changed its major version number in over 10 years. :-)
iOS major version bumps frequently though...
iOS major version bumps frequently though...
"major release" != "major version number"
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.
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.
Well that's very unlikely.
Which is why they dropped OpenSSL.
Here's hoping they never have to enhance their own.
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.
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.
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.