App Store Rejection for using libcrypto.dylib

Tim_Parnell · April 7, 2021, 12:35pm

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

Rick_Araujo · April 7, 2021, 12:43pm

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.

Tim_Parnell · April 7, 2021, 12:46pm

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?

Rick_Araujo · April 7, 2021, 12:50pm

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.

Tim_Parnell · April 7, 2021, 12:51pm

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

Rick_Araujo · April 7, 2021, 12:51pm

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

Sam_Rowlands · April 7, 2021, 12:51pm

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.

Greg_O_Lone · April 7, 2021, 12:52pm

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

Beatrix_Willius · April 7, 2021, 12:53pm

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.

Tim_Parnell · April 7, 2021, 12:56pm

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

github.com

jrgleason/libcrypto/blob/master/LICENSE

GNU GENERAL PUBLIC LICENSE
                       Version 2, June 1991

 Copyright (C) 1989, 1991 Free Software Foundation, Inc., <http://fsf.org/>
 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

                            Preamble

  The licenses for most software are designed to take away your
freedom to share and change it.  By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users.  This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it.  (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.)  You can apply it to
your programs, too.

This file has been truncated. show original

github.com

openssl/openssl/blob/master/LICENSE.txt


                                 Apache License
                           Version 2.0, January 2004
                        https://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or

This file has been truncated. show original

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.

Sam_Rowlands · April 7, 2021, 1:31pm

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?

Beatrix_Willius · April 7, 2021, 1:53pm

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

Tim_Parnell · April 7, 2021, 2:33pm

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.

Thomas_Roemert · April 7, 2021, 5:49pm

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…

Sam_Rowlands · April 8, 2021, 12:39am

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
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).

Horst_Jehle · April 9, 2021, 7:05pm

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.

Tim_Parnell · April 9, 2021, 9:09pm

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?

Jürg_Otter · April 9, 2021, 9:20pm

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

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

Jürg_Otter · April 9, 2021, 9:35pm

We do

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.

Jürg_Otter · April 12, 2021, 8:43pm

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.