OpenSSL 1.1 on OSX

[Grahame Grieve]

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. I can include both openSSL dylibs in my .app
package, and sign all that, but the way libssl loads libcrypto seems to not
meet those rules - which specifically exclude symlinking and which
specifically prohibit loading libcrypto without specifying a specific
version. As far as I can tell anyway, since I can't run the hardened app
under the debugger.

But surely I'm not the first person to want to distribute an application
with openSSL in a hardened run time? And there's lots of information and
discussion of this issue out there on the web, but it's either misleading,
or wrong, or advises you to downgrade to insecure past versions of openSSL,
or just doesn't work, so far as I can tell

Grahame

On Sat, Nov 20, 2021 at 5:28 AM Blumenthal, Uri - 0553 - MITLL <
uri at ll.mit.edu> 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 at openssl.org on behalf of openssl-users at dukhovni.org>
> 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 at healthintersections.com.au
/ +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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211120/9b461766/attachment-0001.html>