OpenSSL 1.1 on OSX

[Grahame Grieve]

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.




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
> > 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.
>
> --
>     Viktor.
>


-- 
-----
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 -
http://www.springer.com/978-3-030-56882-5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211119/a3d046a1/attachment-0001.html>