OpenSSL 1.1 on OSX
hkario at redhat.com
Fri Nov 19 13:02:15 UTC 2021
On Friday, 19 November 2021 07:36:24 CET, Grahame Grieve wrote:
> It's very definitely something active that OSX is doing. Here's
> an OSX error generated:
> System Integrity Protection: enabled
> Crashed Thread: 0 Dispatch queue: com.apple.main-thread
> Exception Type: EXC_CRASH (SIGABRT)
> Exception Codes: 0x0000000000000000, 0x0000000000000000
> Exception Note: EXC_CORPSE_NOTIFY
> Application Specific Information:
> abort() called
> Invalid dylib load. Clients should not load the unversioned
> libcrypto dylib as it does not have a stable ABI.
and you're sure it's trying to load the libcrypto of the OpenSSL 1.1.1,
for example a 0.9.8 version of it?
> On Fri, Nov 19, 2021 at 5:29 PM Viktor Dukhovni
> <openssl-users at dukhovni.org> wrote:
> On Fri, Nov 19, 2021 at 04:31:26PM +1100, Grahame Grieve wrote:
>> I'm trying to get my application that uses openSSL 1.1 running
>> on OSX. I've
>> installed them using homebrew, but I can't get past Apple's gates around
>> blocking use of openSSL.
> I don't think they're actively doing blocking here, though I could
> perhaps be wrong...
>> I've copied both dylibs into my app /Contents/MacOS folder, and signed
>> both of them, and I load them from the that location, but OSX still
>> blocks loading.
> More accurately I think, the libraries fail to load.
>> It actually blocks loading libssl.1.1.dylib, with a message
>> about libcrypto
>> - presumably libssl has a non-version dependence on libcrypto that OSX is
> The problem is likely that "libssl" not built to locate "libcrypto"
> relative to its own location, but rather expects to find it at a fixed
> location. This would be some MacOS-specific instance of setting the
> runpath to $ORIGIN on ELF systems.
> With OpenSSL installed at a fixed location, OpenSSL is working just
> fine for me (and of course in HomeBrew, ...).
> So the issue most probably the inability of "libssl.dylib" to find
> "libcrypt.dylib", not because of some policy enforcement by Apple's
> evil overlords, but simply because the runtime linker does not
> expect to look in the location where you have libcrypt installed.
> The only thing that gives me some pause is Whether or not notarisation
> also complicates relocation, but presumably applications can ship
> shared libraries with the application code without running into
> major obstacles.
> Perhaps the presence of LibreSSL on MacOS is another complication,
> but that libssl and libcrypt should have different version suffixes,
> and should not get in the way, provided that MacOS has something
> akin to symbol versioning, to allow separate API versions of the
> same library to exist in a process side by side without getting
> in each other's way.
> If the symbol namespace in MacOS is "flat", then you may indeed
> run into trouble because of symbol conflicts between the real
> OpenSSL and the LibreSSL fork.
> Good luck.
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
More information about the openssl-users