Forum > macOS / Mac OS X

Synapse and Catalina SSL causing crash

(1/6) > >>

Josh:
Hi

Hope someone can help, and its not too complicated.

I have a app that gets incrypted data from company server, the app is working fine on everything up to Catalina, but when run on catalina it crashes out on start up. error below. The app is a company app and as such is not through the App Store.

I am using synapse fro the HTTP and HTTPS routines, as i also have windows clients of the app.

Is their a way around the New apple security system, or maybe does anyone know of an alternative HTTP HTTPS unit for osx (that is native) to by pass synapse for osx deployment, if so how can i configure a build option that does not add the lazsynapse requirement.


--- Quote ---Application Specific Information:
/usr/lib/libcrypto.dylib
abort() called
Invalid dylib load. Clients should not load the unversioned libcrypto dylib as it does not have a stable ABI.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib           0x00007fff65a3d7fa __pthread_kill + 10
1   libsystem_pthread.dylib          0x00007fff65affbc1 pthread_kill + 432
2   libsystem_c.dylib                0x00007fff659c4a1c abort + 120
3   libcrypto.dylib                  0x00007fff6333b804 __report_load + 352
4   dyld                             0x000000011602e15d ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 539
5   dyld                             0x000000011602e582 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
6   dyld                             0x0000000116028dc7 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 493
7   dyld                             0x0000000116026e58 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 188
8   dyld                             0x0000000116026ef8 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 82
9   dyld                             0x0000000116018f87 dyld::runInitializers(ImageLoader*) + 82
10  dyld                             0x0000000116022ad7 dlopen_internal + 609
11  libdyld.dylib                    0x00007fff658e1a7f dlopen + 171
12  com.company.editor               0x000000010777935a 0x10764f000 + 1221466
13  com.company.editor               0x000000010765fc1f SYSTEM_$$_LOADLIBRARY$RAWBYTESTRING$$INT64 + 15
14  com.company.editor               0x0000000107ac2246 SYNAFPC_$$_LOADLIBRARY$PCHAR$$INT64 + 86 (synafpc.pas:109)
15  com.company.editor               0x0000000107acf849 0x10764f000 + 4720713
16  com.company.editor               0x0000000107acf919 SSL_OPENSSL_LIB_$$_INITSSLINTERFACE$$BOOLEAN + 175
17  com.company.editor               0x0000000107ac8067 INIT$_$SSL_OPENSSL + 10
18  com.company.editor               0x000000010765cdcc FPC_INITIALIZEUNITS + 60
19  com.company.editor               0x000000010765058d PASCALMAIN + 10

--- End quote ---

Regards

Josh

Hansaplast:
Catalina doesn't seem to like OpenSSL anymore.
Instead (depending if it fits your needs) use the MacOS API.
See also my other post in the forum: here.

Short version:

Under more recent macOS versions (at least as of Mojave), fphttpclient will not work.
Apple does not seem to like the OpenSSL library (default macOS setup!):


As an alternative for macOS users, use the unit "ns_url_request" by Phil Hess (file can be found here - Phil's Mac related page).
This does not require any extra libraries (beyond what comes with macOS).


A quick (and sloppy) function pulling in HTTPS content as a string:




--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---uses ... ns_url_request ... // Note: "ns_url_request" uses also Phil's "NSHelpers" unit. ... function TForm1.GetURLContent(aURL:string):string;var  HTTP: TNSHTTPSendAndReceive;begin  HTTP := TNSHTTPSendAndReceive.Create;  HTTP.Method   := 'GET';  HTTP.Address  := aURL;  HTTP.SendAndReceive(Result);  HTTP.Free;end;  

Jonas Maebe:

--- Quote from: Hansaplast on February 08, 2020, 01:17:06 pm ---Catalina doesn't seem to like OpenSSL anymore.

--- End quote ---

Even if that is true, that has absolutely nothing to do with the error message.

The issue is that OpenSSL does not provide ABI compatibility between different versions. That means that if you load the unversioned libcrypto.dylib, you may get a version of the library that uses a different ABI than the one you expect. That can lead to bugs like buffer overflows, reading uninitialised memory, or other undefined behaviour. These are sources of security holes and hence things you definitely don't want to happen when using a crypto library.

The solution is to explicitly load either /usr/lib/libcrypto.0.9.7.dylib or /usr/lib/libcrypto.0.9.8.dylib, depending on which version of OpenSSL your (Synapse) interface uses. At first sight, this needs to be fixed in a unit called ssl_openssl_lib.

Hansaplast:
You're right, better explained than I did ...


My only concern with that, is that on another Mac, now or in the future, that particular library version may or may not be installed on their system?
So one may have to distribute that exact version of OpenSSL (and all that comes with it) with your application to avoid that?
Where as the other approach would not only rely on Apple's API.


(please correct me if I'm wrong)

Jonas Maebe:

--- Quote from: Hansaplast on February 08, 2020, 03:33:22 pm ---You're right, better explained than I did ...


My only concern with that, is that on another Mac, now or in the future, that particular library version may or may not be installed on their system?
So one may have to distribute that exact version of OpenSSL (and all that comes with it) with your application to avoid that?
Where as the other approach would not only rely on Apple's API.

--- End quote ---

Apple also merrily deprecates and removes its own APIs from time to time, so that's not really safer in general.

Navigation

[0] Message Index

[#] Next page

Go to full version