I am having my apps rejected by Apple at the moment.
“Clients should not load the unversioned libcrypto dylib as it does not have a stable ABI.”
Does the XojoFramework crypto libraries use this dylib?
No, we build our own static version. Maybe you can use “otool -L” to find the culprit.
Thanks @William Yu this is good to know, it means I only have to deal with it in one place. Thank you answering so quickly too.
I checked using App Wrapper which processes the Mach-O file and I also just tried your suggestion, it’s not listed for either. However I do where in my code I am calling this library, but I don’t know what to do about it.
I’ve gone through all the OS versions that my apps support and there’s a wide variety of libraries I could link against. Look like I might have to devise a system to pick different libraries per OS version, is this even possible with declares?
I’m also unable to make the error occur on my testing machines (of which I currently have 3). So I’m wondering if this is specific to the reviewers machine, or there’s a reason as to why my installations of Catalina are not correct (one is upgraded and one is clean).
Can I tap into your library using declares? I am using “d2i_PKCS7_fp”, “PKCS7_free”, “OBJ_obj2nid”, “ASN1_get_object” and “SHA1”?
This is a bug in macOS and shouldn’t be a reason for rejecting. Are you using AquaticPrime? Then change your definition of LibCrypto to
/usr/lib/libcrypto.0.9.8.dylibAnd no you can’t use different versions of the dylib for different versions of macOS.
Bugz in the macOS, say it isn’t so!
Nope, but I am using the library when assessing the App Store Receipt.
Thanks, I’ve resubmitted for the moment, perhaps a different reviewer and such.
[quote=476512:@Beatrix Willius]
And no you can’t use different versions of the dylib for different versions of macOS.[/quote]
Which I find a bit odd IMHO, the current solution as it seems (until 10.15 at least) is for the macOS to include a symbolic link to a version, but it appears to use different versions on different versions of the macOS.
Plus with Apple harping on about security, surely they’d want devs to use newer versions of this library, rather than one from the mid 10s?
I also think that using a newer version would make sense security wise. But most of the times bug fixes take a long time with Apple. I noticed the bug - like - half a year ago???
I just got feedback from another Apple developer, supposedly we’re not meant to use the libraries that Apple ships, and this issue is Apple clamping down on it’s use.
https://forums.developer.apple.com/thread/124782
I’m going to stop and consider my options, of which I can see several.
Thanks @Beatrix Willius for your help.
After reading the thread I want to put my head on the desk. How are you supposed to know which libraries are okay and which are not? The AquaticPrime code needs to be rewritten anyways. With the thread you linked to I’d better do this for Crapolina times 2.
Can’t you use the built-in crypto functions or the one in our MBS Xojo Encryption Plugin?
That would avoid relaying on openssl libraries.
@Christian Schmitz: yes, that’s what I’m going to do. I really didn’t want to change the Aquatic Prime code until I had to.
[quote=476512:@Beatrix Willius]Then change your definition of LibCrypto to
/usr/lib/libcrypto.0.9.8.dylib[/quote]
Been thinking and reviewing my options to solve this; you’re suggestion seems like the winner at the moment, least resistance, solves the problem today and saves me from having to re-write any code.
Soon the list of things that we used to use from Apple will be longer than the list of things that we can use.
[quote=476518:@Sam Rowlands]I just got feedback from another Apple developer, supposedly we’re not meant to use the libraries that Apple ships, and this issue is Apple clamping down on it’s use.
[/quote]
that thread seems to say we’re not to use ones that are not officially part of the macOS SDK - regardless of the original source.
and libcrypto doesnt appear to have an official header file from apple in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/
or the other option they do suggest is “build your own version and use that” which is basically what MBS has done
Well waddya know, I didn’t make any changes, instead just re-submitted in the hopes that I’d get a different reviewer, and it might get approved… And that worked! App was approved overnight.
wow … talk about random rule application 
Yup, I’ve always assumed it to be the case, as I’ve been rejected for stuff that others haven’t. Now I’ve just proved it to be the case.
One year later we have the reason for this rejection - under BS 11.1 on a M1 MacMini app start of a UB app is aborted when app is trying to use “/usr/lib/libcrypto.dylib” in declares:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
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.
@Sam_Rowlands - these declares are part of the AppStoreReceipt - did you change the declares to use the libcrypto from xojo or is using “/usr/lib/libcrypto.0.9.8.dylib” a solution?
At the time, re-submission worked for me.
However, looking at Iconographer Mini, the constant uses “/usr/lib/libcrypto.0.9.8.dylib”.
Public Const kLibCrypto as String = /usr/lib/libcrypto.0.9.8.dylib
Which doesn’t exist on my BS installation, in fact there are no libcrypto files there at all. They’re now all hidden, so I have no idea what versions are available. Good Job Apple.
Apple is simply crazy. Why is the file now a secret?
Find Any File tells me that some apps now bring their own:
libcrypto.0.9.8.dylib results in a FunctionNotFoundException, so I switched to libcrypto.35.dylib. This one works fine (app update got approved in Mac App Store yesterday and app start is not aborted on BS 11.1 on M1 Macs) and is also present on older systems (librypto symlink on my Mojave points to this version).
1 Like