Re: OpenSSL 1.1 on OSX

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

 



The problem is that symlinking doesn't work in this case. Sure, I can install openSSL, and then it works. For me. But I'm trying to distribute an application, and to do that on modern macs, I need a hardened run time. And the rule for that is that all code your application uses must be signed either by you or by apple.

 

It is trivial to install OpenSSL-1.1.1 via Macports, and build/link an app with hardened run time against it. XCode offers an option to embed and sign the libraries you’re linking against.

 

Another option is to state in the docs that this app depends on user installing Macports port “openssl11”.

 

If neither option is sufficient, I can’t help you, sorry.

 

 

On Sat, Nov 20, 2021 at 5:28 AM Blumenthal, Uri - 0553 - MITLL <uri@xxxxxxxxxx> wrote:

Here's how Macports did it:

1. Installed OpenSSL-1.1.1 into /opt/local/libexec/openssl11;
2. Installed OpenSSL-3.0.0 into /opt/local/libexec/openssl3;
3. Symlinked OpenSSL-3.0.0 libraries into /opt/local/lib (primary directory where stuff lives);

I added symlinking /opt/local/libexec/openssl11/lib/libcrypto.1.1.dylib into /opt/local/lib too.

This allows compiling new apps against OpenSSL-1.1.1 in /opt/local/libexec/openssl11. Old binaries do not need to be recompiled, as they can find libcrypto.1.1.dylib and libssl.1.1.dylib in the "standard" location (/opt/local/lib).

Hope this helps.
--
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, 13:16, "openssl-users on behalf of Viktor Dukhovni" <openssl-users-bounces@xxxxxxxxxxx on behalf of openssl-users@xxxxxxxxxxxx> wrote:

    On Fri, Nov 19, 2021 at 05:36:24PM +1100, 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.

    Well, I think that's evidence of confusion about which "libcrypto" to
    load.  It sure seems that you're trying to load the default system
    libcrypto, not the one in the application bundle.

    You should probably arrange to "salt" the names of the libssl and
    libcrypto libraries used by your application, so that there can't
    be any confusion with the platform's libssl and libcrypto.

    May also need to do something to avoid symbol name collisions, but I
    haven't looked into how that works on Darwin, so can't offer specific
    advice.

    --
        Viktor.


 

--

-----
http://www.healthintersections.com.au / grahame@xxxxxxxxxxxxxxxxxxxxxxxxxx / +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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[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