notarytool not recognizing a zip created with ditto

Code Signing Notarization
mcarriere OP
Created Mar ’23
Replies 6
Boosts 0
Views 1.8k
Participants 2

We're in the process of updating an app that we released approximately a year ago -- which had no issues with codesigning and notarization in our last release.

The current version fails at the initial submission process; stating that the file "must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg)"

The process itself we're taking is rather straightforward, and follows much of what I've seen repeated on the forums here.

A few additional details:

  • The app itself (a Unity project with a lot of content that needs to be shipped with the app) is quite large, weighing in at around 20GB.

  • Despite this large size, we were able to go through this process in the past with no issues.

  • I was originally running Xcode 13 on Big Sur, but upgraded to Xcode 14 on Ventura to no avail.

Our notarization script runs the following:

ditto -c -k --keepParent OurAppName.app NotarizationFileName.zip

xcrun notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait

When we add --verbose to the xcrun command; this is our output:

$ Build > xcrun notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait --verbose

[23:01:54.643Z] Debug [MAIN] Running notarytool version: 1.0.0 (27), date: 2023-03-25T23:01:54Z, command: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait --verbose
Conducting pre-submission checks for NotarizationFileName.zip and initiating connection to the Apple notary service...

[23:01:54.717Z] Info [PREFLIGHT] NotarizationFileName.zip is not a zip archive. warning [/Users/michael/.jenkins/workspace/bastion-add-build-tools/Build/NotarizationFileName.zip]:  17179869184 extra bytes at beginning or within zipfile
  (attempting to process anyway)
. Err: 1

[23:01:54.729Z] Debug [PREFLIGHT] NotarizationFileName.zip did not pass the disk image potentiality test. Moving on to other tests.

[23:01:54.730Z] Debug [PREFLIGHT] NotarizationFileName.zip is not a flat installer package.

[23:01:54.731Z] Debug [PREFLIGHT] Finished completing determination of file type for NotarizationFileName.zip. Operation took 80ms.
Error: NotarizationFileName.zip must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg)

Usage: notarytool <subcommand>
  See 'notarytool --help' for more information.
Answered by DTS Engineer in 750174022

The immediate workaround is to continue using altool.

After talking with the notary team about this issue, I have two new workaround suggestions that allow you to stick with notarytool:

  • Use the --force option to disable the notarytool preflight check.

  • Use some other tool to create your zip archive, like the Finder or zip.

IMPORTANT If your product uses extended attributes, don’t use the zip tool because it does not preserve those.

We believe that the preflight check is correct and the actual problem lies with ditto, but either of the above options let you continue your move to notarytool while we sort out the details.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies  6
Boosts  0
Views  1.8k
Participants  2
DTS Engineer OP
Apple
Mar ’23

If you run the same process with a smaller test app — say one you create from one of Xcode’s built-in templates — do you see the same issue?

My best guess here is that the size of the archive is causing ditto to create a 64-bit zip which is then tripping up the preflight check done by notarytool.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
mcarriere OP
Mar ’23

Using a smaller version of the app that didn't include the main content packs the app needs to ultimately run, I was able to create an app at around 1GB in size. This successfully was able to be sent to notarization and be successfully notarized.

I looked back at our last submission, which was on Mar 4, 2022, and it turns out we were using altool at the time for submission and notarization. It would seem that notarytool has a regression that you're already aware of in this regard.

How can we work around this to get our application notarized?

0
DTS Engineer OP
Apple
Mar ’23

It would seem that notarytool has a regression that you're already aware of in this regard.

I was not specifically aware of this, I’m just good at guessing (-:

I’d appreciate you filing a bug against notarytool. It would help if you could attach the zip archive that fails the preflight but that’s not 100% necessary. I was able to reproduce this with a dummy zip archive.

Please post your bug number, just for the record.

Curiously, we have see this problem before (r. 76027910), and it was reported as fixed at the time, so something has regressed.

How can we work around this to get our application notarized?

The immediate workaround is to continue using altool.

Beyond that, it kinda depends on the final deployment process for your app. Do you actually ship this zip archive to customers? Or something else?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
mcarriere OP
Mar ’23

@eskimo -- Thank you so much!

We reverted to using altool and were able to successfully notarize our application for our update build. We should be good at this point.

As requested, I filed a bug about notarytool (FB12080461)

0
DTS Engineer OP
Apple
Apr ’23
Accepted Answer

The immediate workaround is to continue using altool.

After talking with the notary team about this issue, I have two new workaround suggestions that allow you to stick with notarytool:

  • Use the --force option to disable the notarytool preflight check.

  • Use some other tool to create your zip archive, like the Finder or zip.

IMPORTANT If your product uses extended attributes, don’t use the zip tool because it does not preserve those.

We believe that the preflight check is correct and the actual problem lies with ditto, but either of the above options let you continue your move to notarytool while we sort out the details.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
DTS Engineer OP
Apple
Jul ’23

If you previously worked around this bug, please try again with the notarytool from Xcode 15 beta.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
notarytool not recognizing a zip created with ditto
First post date Last post date
 
 
Q