Re: OpenSSL 1.1 on OSX

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

 



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.



[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