OpenSSL 1.1 on OSX

[Blumenthal, Uri - 0553 - MITLL]

I don't use Brew. I've installed OpenSSL-1.1.1 (and 3.0.0) via Macports, and have no problem linking and running apps against 1.1.1.

--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 11/19/21, 08:03, "openssl-users on behalf of Hubert Kario" <openssl-users-bounces at openssl.org on behalf of hkario at redhat.com> wrote:

    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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211119/bf72f4b3/attachment-0001.bin>