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@xxxxxxxxxxx on behalf of hkario@xxxxxxxxxx> 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@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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
