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-us...@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 / grah...@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
