Mac vs Open Source
I develop software.
The kind of software I work on rarely concerns itself with details of the platforms it runs on, and is therefore inherently platform-neutral. Of course complete cross-platform compatibility is elusive, but one does one’s best to adhere to widely-supported standards, libraries known to be cross-platform, etc. And if something non-standard is unavoidable, try to package it so that switching it out will be clean and straightforward as and when someone has the need.
So it’s with some concern that I see the Mac platform apparently moving to distance itself from the open source world I inhabit. I’ve got used to the idea that I sometimes have to use clang instead of gcc, and that that gives rise to annoying gotchas when autoconf stuff picks up gcc/g++ in spite of the standard names cc, c++ et al all being the clang versions! Still, I guess it’s not the platform’s fault if
CC=cc CXX=c++ ./configure –options
Now it’s OpenSSL that’s been giving me grief. Working with it on Mac for the first time, I see all the OpenSSL APIs I’m using appear to be deprecated. Huh? Googling finds that the whole of OpenSSL is deprecated on Mac. Thou shalt use CC_crypto(3cc) instead! Damn!!
OK, what’s CC_crypto? Given that lots of software I work on uses OpenSSL, it’s only going to be of interest if it emulates OpenSSL (well, if for example it was an OpenSSL fork then that would be a reasonable expectation). There’s a CC_crypto manpage, and google finds similar information at Apple’s developer site, but therein lies nothing more enlightening than cryptic hints:
To use the digest functions with existing code which uses the corresponding openssl functions, #define the symbol COMMON_DIGEST_FOR_OPENSSL in your client code (BEFORE including <CommonCrypto/CommonDigest.h>).
The interfaces to the encryption and HMAC algorithms have a calling interface that is different from that provided by OpenSSL.
Well, if that means it’s mostly OpenSSL-dropin-compatible, why not say so? Even googling “CC_crypto openssl emulation” doesn’t turn up anything that looks promising, so I haven’t found any relevant documentation. And since the header files are different, it will at the very least require some preprocessor crap. OK, ignore it, stick to OpenSSL, kill off the -Werror compiler option, and maybe revisit the issue at some later date.
Not good enough. The build bombs out when something (not my code, and I’d rather not have to hack it) uses HMAC functions, whose signature on Mac is different to other platforms. So openssl on Mac – specifically /usr/include/openssl/hmac.h – is nonstandard! Grrr … In fact it appears to be some bastardised hybrid: OpenSSL function names with CCHmac-like declarations. Is this OpenSSL in fact a wrapper for CC_crypto? If so, why is it all deprecated? Or if not, who has mutilated the API?
Well OK, that’ll be what Homebrew was talking about when it flashed up some message about installing OpenSSL only under Cellar, and not as a standard/system-wide lib. So I have another OpenSSL. Perhaps more? locate hmac.h finds a whole bunch of versions (ignoring duplicates and glib’s ghmac.h):
Of those, only the Cellar version is compatible with the canonical OpenSSL. A –with-openssl configure option fixes my immediate problem, but throws up a bunch of questions:
- Why have I had to jump through these hoops?
- Where would I start if I want to use CC_crypto as advised in existing OpenSSL-using code?
- What do I need to keep up-to-date on my system? Presumably standard apps use the version in /usr , but is anything keeping that updated if homebrew isn’t touching it?
Dammit, looks like this Mac may be vulnerable! Everything in /usr/include/openssl is dated 2011 (when the macbook was new). The libssl in /usr/lib is dated September 2014 – which suggests it has been updated by some package manager. But it identifies itself as libssl.0.9.8, which is not exactly current. Maybe it’s a Good Thing the macbook’s wifi died, so it no longer travels with me outside the house.
WTF is Apple doing to us?