mz_crypt_apple.c references non-public symbols #708
Comments
|
If you want to add ifdef in those functions for iOS then I can accept PR. Just return MZ_SUPPORT_ERR; |
Is this also happened when you build a framework based on minizip-ng and using the framework instead of the source code of minizip-ng in your app??? |
|
Yes, the minizip-ng is included in a framework which is included in the app.
Just downgraded to the 3.x version and was able to upload the app to Apple.
Richard.
…-------- Original Message --------
On Jun 4, 2023, 21:42, Nick Brighten wrote:
> Just upgraded minizip-ng to 4.0.0 in my iOS app. Uploading it to Apple fails with error
>
> The app references non-public symbols in Payload/[...]: _CCCryptorGCMAddAAD, _CCCryptorGCMAddIV, _CCCryptorGCMDecrypt, _CCCryptorGCMEncrypt, _CCCryptorGCMFinal (ID: 03667ee6-51bf-479f-b8b8-3c6253e65a3a)
>
> The new section at the top of mz_crypt_apple.c copies declarations of CCCryptorGCMAddAAD etc.
>
> Using private API blocks using this library in iOS/macOS apps.
Is this also happened when you build a framework based on minizip-ng and using the framework instead of the source code of minizip-ng in your app???
—
Reply to this email directly, [view it on GitHub](#708 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AALVBO3OM3ZOJCHO2PHT35TXJTQLLANCNFSM6AAAAAAY2BGU4I).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
The implementation of CCCryptorStatus in minizip-ng (mz_crypt_apple) uses private API methods that don't go through the Apple review process... API methods to use would be: Everything is fine in minizip-ng version 3.0.10 because official API methods are used. |
|
Hi Nathan,
This is an Apple specific file. The API used is public neither for iOS and macOS, so I can ifdef it and it will basically never be used, so that seems not right.
I think the better (if not only) way to implement GCM support, is by using official API only.
Richard.
…------- Original Message -------
On Sunday, June 4th, 2023 at 21:06, Nathan Moinvaziri ***@***.***> wrote:
If you want to add ifdef in those functions for iOS then I can accept PR.
—
Reply to this email directly, [view it on GitHub](#708 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AALVBOZDVJARAEV2JQ6YGUTXJTMDFANCNFSM6AAAAAAY2BGU4I).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Exactly, thanks Nick. I reverted to version 3.0.9 and the app submission was accepted by Apple.
Richard.
…------- Original Message -------
On Sunday, June 4th, 2023 at 22:27, Nick Brighten ***@***.***> wrote:
The implementation of CCCryptorStatus in minizip-ng (mz_crypt_apple) uses private API methods that don't go through the Apple review process...
API methods to use would be:
CCCryptorStatus CCCryptorCreateFromData
CCCryptorStatus CCCryptorCreate
CCCryptorStatus CCCryptorCreateFromDataWithMode
CCCryptorStatus CCCryptorCreateWithMode
CCCryptorStatus CCCryptorRelease
CCCryptorStatus CCCryptorUpdate
CCCryptorStatus CCCryptorFinal
CCCryptorStatus CCCryptorReset
CCCryptorStatus CCCryptorGetIV
CCCryptorStatus CCCrypt
CCCryptorStatus CCCryptorEncryptDataBlock
CCCryptorStatus CCCryptorDecryptDataBlock
Everything is fine in minizip-ng version 3.0.6 because official API methods are used.
—
Reply to this email directly, [view it on GitHub](#708 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AALVBO6XPY5VB5BPEN2JCODXJTVUZANCNFSM6AAAAAAY2BGU4I).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
The problem is the method "getRealCryptor" in "CommonCryptorGCM.c" - that is an private method and in "mz_crypt_apple.c" their will be used with "CCCryptorGCMAddAAD" and more... |
|
Only the functions I had to declare at the top are private. Using ifdef are fine and it will just not support GCM on iOS. Zip format itself doesn't need it. It is just such for completeness if anybody wants to use classes for other purposes. I don't know if any other native functions for it on macOS/iOS that don't require swift or objective C. |
|
Btw it is possible to notarize a macOS app linking to these functions. It could be a function of submitting it to AppStore and not a function of notarization. |
|
Thanks, I will give the ifdef approach a try on the next app update (both iOS and mac Catalyst), if the app is accepted I will send the PR. This will probably take two weeks. I will report back here. |
That's not true - you define it above, but use it for the first time in the code starting at line 228... What's the point of implementing GCM for ZIP if ZIP doesn't require it? There are also other libraries for AES encoding and decoding that can do far more than GCM... |
The function names are the same.
I use it for another project.
Thanks, but I'm not interested in those other projects. Like I said, I am open to PR. If not you can go back to using older version. That is why the change in version from 3.x to 4.x, because there is likely to be some breakage. Or you can use another ZIP library if you don't like the way I manage this one. |
|
I may have broke it again with #804. Alternatively, you will need to define MZ_TARGET_APPSTORE in all your apps. |
|
Ah, never mind, already fixed in b2691a0 |
Just upgraded minizip-ng to 4.0.0 in my iOS app. Uploading it to Apple fails with error
The app references non-public symbols in Payload/[...]:
_CCCryptorGCMAddAAD, _CCCryptorGCMAddIV, _CCCryptorGCMDecrypt,
_CCCryptorGCMEncrypt, _CCCryptorGCMFinal (ID:
03667ee6-51bf-479f-b8b8-3c6253e65a3a)
The new section at the top of mz_crypt_apple.c copies declarations of CCCryptorGCMAddAAD etc.
Using private API blocks using this library in iOS/macOS apps.
The text was updated successfully, but these errors were encountered: