OpenSSL 1.1 on OSX

[Hubert Kario]

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, 
not,
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
>> 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.
>

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic