OpenSSL 1.1 on OSX
grahame at healthintersections.com.au
Fri Nov 19 06:36:24 UTC 2021
It's very definitely something active that OSX is doing. Here's an OSX
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:
Invalid dylib load. Clients should not load the unversioned libcrypto
dylib as it does not have a stable ABI.
On Fri, Nov 19, 2021 at 5:29 PM Viktor Dukhovni <openssl-users at dukhovni.org>
> 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.
> > 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
> > - presumably libssl has a non-version dependence on libcrypto that OSX is
> > blocking?
> 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.
http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
Benson & Grieve: Principles of Health Interoperability (Health
Information Technology Standards), 4th ed -
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users