Re: OpenSSL 1.1 on OSX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx> 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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux