App Store Rejection for using libcrypto.dylib

OpenSSL provides two primary libraries: libssl and libcrypto. The libcrypto library provides the fundamental cryptographic routines used by …

libcrypto is OpenSSL.
https://www.google.com/search?q=libcrypto

Nope. It’s just the cryptographic lib used by it.

" The OpenSSL crypto library implements a wide range of cryptographic algorithms used in various Internet standards. … libcrypto consists of a number of sub-libraries that implement the individual algorithms."

https://www.openssl.org/docs/man1.0.2/man3/crypto.html

OpenSSL depends on it.

That sentence does not mean that OpenSSL is not libcrypto? Did you follow my Google link?

Additionally, the phrase “dep” does not exist on that page. It is not a dependency per that page.

Also, that does not help anyone trying to use libcrypto package it up. While my posts, do. Please don’t derail the thread to um-actually me… again. I’m so sick of you trying to do that.

Lastly, have you ever built OpenSSL yourself?

I’ll won’t discuss about it. It will be a silly talk. I also published a link, from the source. Just read about it deeper.

That’s all I ask, but next time in the future - do that before you post.

Hey man, you are exaggerating. Please, have manners.

Alright. so it is late here. I’ll have a think tomorro, maybe there’s a way I can redesign my class to accommodate both and still use the built-in libraries for Mac OS.

If you include libcrypto within your application, there is licensing which must be taken into consideration and I don’t have the brain power to deal with that right now.

@Tim_Parnell @Rick_A
Bickering adds nothing to this conversation. Please take your conversation offline.

1 Like

Let’s say that libcrypto is NOT ONLY OpenSSL. These are some declares that I found in the old code:

Declare Function RSA_public_decrypt Lib CryptoLib (flen as integer, from as Ptr, mto as Ptr, rsa as Ptr, padding as integer) As integer
Declare Function ERR_error_string Lib CryptoLib (e as Integer, buf as Ptr) As CString
Declare Function ERR_get_error Lib CryptoLib () as Integer
Declare Function SHA1_Init Lib CryptoLib (c as Ptr) As integer
Declare Function SHA1_Update Lib CryptoLib (c as Ptr, data as CString, mlen as integer) As integer
Declare Function SHA1_Final Lib CryptoLib (md as Ptr, c as Ptr) As integer

I would prefer not to convert those to Xojo code. But the alternative of linking to the dylib also doesn’t sound like much fun.

2 Likes

If no one calls it out publicly, the toxic attitude will continue. This attitude needs to stop. I’m taking my stand. Where are the moderators?

@Sam_Rowlands the licensing for both seems pretty straight forward

I’m done helping here, I guess. It’s not like I’ve packaged up libcrypto more than once for deployment or anything. Not like I know the exact answer to Help calling a function from dylib If you want to get it working, I guess I need to take my discussions offline.

Please don’t leave. I is tired and may not fully understand the ins and outs of the whole process.

I know something needs to change, and I can’t think very clearly right now. All I can see is that there are multiple copies installed in the OS, Xojo also includes a libcrypto with our built apps, I’d like to try to find a way how we figure this out, preferably without having to include another copy of libcrypto somewhere in the app, but if it really comes to that.

Right now, I only need to use libcrypto to parse App Store receipts, maybe having another copy of libcrypto just for App Store builds isn’t such a bad thing?

@Greg_O_Lone is the libcrypto dylib that Xojo includes in built apps, a full copy of libcrypto or just the functions that Xojo exposes? i.e. Can we declare into Xojo’s library to call all libcrypto functions, or just a select set of functions?

Please don’t leave. Would you share your packaging? I don’t mind paying money for code.

1 Like

For those concerned by my post, I don’t mean that I plan to leave… Though, I’m not going to stick around to be targeted when I have actually solved this issue more than once.

I have reached out to Sam and Beatrix offline.

2 Likes

You can still use libcrypto.35.dylib for this purpose, it works fine from macOS 10.11 (“El Capitan”) through macOS 11.2 (“Bg Sur”), all my apps in the Mac App Store use this one…

In some of my apps I still support 10.10 Yosemite.

  • HDRtist NX 2 only requires 10.11 because I went all in on Metal. When I started beta testing did I realize that Metal is only standard on 10.14, so I had to support OpenGL as well.
  • Iconographer Mini requires 10.16, only because Apple won’t let me include their icons in my App Store apps, so to get the BS templates it has to be run on BS. But Catalina or below templates are not allowed :frowning:
  • App Wrapper 4 only requires 10.13.6 because Apple do not offer Notarization for system below that.

As not much else has changed (except Apple renaming functions for change sake) most of my apps and functionality still work on 10.10, even Dark Mode (albeit they changed many color names too).

My immediate goal is to try to get this class so it can use either dylib at the moment. If I am unsuccessful, then I investigate other options (including @Tim_Parnell suggestion of bundling a libcrypto.dylib with my apps).

Now I have tried all dylib releases 0.9.8, 1.0, 1.0.1, 35, 41 etc. The result is, that the application doesn’t run when it was complied with Xojo 2021R1, and the error is the same:

Invalid dylib load. Clients should not load the unversioned libcrypto dylib as it does not have a stable ABI.

Also I have tried this application on macOS 10.15.6 and the error is also the same.

When I build my application with the same source code and Xojo 2020R2.1, the application runs without any error.

That error message seems to indicate you’re still referencing the unversioned shared copy of libcrypto, which as I already mentioned above, Apple does not want you to do.

Have you tried building and bundling libcrypto into your application like Apple recommends?

1 Like

That’s because 2021r1 is linking your applications against the macOS 11 SDK (Intel & ARM), whereas 2020r2 is linking Intel-builds against an older macOS SDK (but ARM of course having to use macOS 11 SDK).

It seems to me that it’s just no longer allowed to load an unversioned (libcrypto) dylib when using the macOS 11 SDK.

Ah, you’ve just written that, too - but posted before me :slight_smile:

Example:

Const cryptoLib = "/usr/lib/libcrypto.dylib"

Declare Function SSLeay_version Lib cryptoLib (i As Integer) As CString
Dim v As String = SSLeay_version(0)
Break

This works just fine with Xojo 2020r2 on macOS 11.2
It crashes when compiled with 2021r1 (as explained and shown in posts above).

If I specify a version for the dylib, then I get the following results with 2021r1 on macOS 11.2:

Const cryptoLib = "/usr/lib/libcrypto.dylib"
'Result: ___crash___

Const cryptoLib = "/usr/lib/libcrypto.0.9.8.dylib"
'Result: v = OpenSSL 0.9.8zh 14 Jan 2016

Const cryptoLib = "/usr/lib/libcrypto.35.dylib"
'Result: v = LibreSSL 2.2.9

Const cryptoLib = "/usr/lib/libcrypto.41.dylib"
'Result: v = LibreSSL 2.5.5

And just fyi… Xojo 2020r2 on macOS 11.2 will get you this:

Const cryptoLib = "/usr/lib/libcrypto.dylib"
'Result: v = LibreSSL 2.2.9

We do :wink:

And I’d encourage everyone to do so… Otherwise you have a dependency on it’s availablity by the OS. And that might change with every OS version. So your app might break with an updated macOS version. At the very least you’d need proper checks and error handling.

Trying to sum up the possible issues mentioned in this Thread:

  • Using /usr/lib/libcrypto.dylib is no longer possible with Xojo 2021r1 (and most likely 2020r2 and macOS-ARM64)
    It seems to me that the newest macOS SDK enforces this. But there might also come a macOS update preventing that sooner or later for existing apps - one never knows…
  • /usr/lib/libcrypto.0.9.8.dylib is not available for macOS-ARM64 - meaning Apple doesn’t supply it with macOS 11.
    Not surprising that Apple hasn’t compiled and provided such an old library for their newest target…

So either we have to use a specific version which means error-checking if it exists (and then use/try other versions), as not all OS versions have the same lib-versions available. And it might change anytime since it’s out of our control.

Or (such as Apple seems to recommend) build an own .dylib and bundle it within the application. Which certainly has the benefit that one knows exactly which version it is - and can make sure the Declares work.

Again not quite surprising… OpenSSL 0.9.8 and 1.1.1 have quite some differences in the API. From that point of view, I understand Apple wants us to link against a specific version.

1 Like
Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.