4 Replies
      Latest reply on Nov 2, 2019 12:48 PM by mheins
      yhnfc Level 1 Level 1 (0 points)

        For years, we have been using the following four commands to sign our app and ensure that the signing has worked:


        codesign --force --verbose=0 --deep --sign $certIdentity $mntpointApp

        codesign --verify --verbose=0 --deep $mntpointApp

        spctl --assess --verbose=4 --type install $mntpointApp

        spctl --assess --verbose=4 --type execute $mntpointApp


        Our build machine (macOS 10.13.6, Xcode 10.1) executes these commands without failure. My Mohave MBP did too before I upgraded it to Catalina and Xcode 11.


        After upgrading, the first spctl command fails like this (according to our gradle script's output):


        13:14:54.010 [INFO] [org.gradle.process.internal.DefaultExecHandle] Starting process 'command 'spctl''. Working directory: $HOME Command: spctl --assess --verbose=4 --type install $HOME/build/tmp/dmgMount/My.app

        13:14:54.010 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTING

        13:14:54.010 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Waiting until process started: command 'spctl'.

        13:14:54.014 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTED

        13:14:54.014 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] waiting until streams are handled...

        13:14:54.014 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'command 'spctl''

        13:14:54.238 [ERROR] [system.err] $HOME/build/tmp/dmgMount/My.app: rejected

        13:14:54.239 [ERROR] [system.err] source=Unnotarized Developer ID

        13:14:54.239 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: FAILED

        13:14:54.239 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Process 'command 'spctl'' finished with exit value 3 (state: FAILED)


        I modified the above debug output to obfuscate a couple of names that I don't want to reveal.


        The doc that I've been reading, regarding how to notarize and staple is this: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution


        The first bullet under the heading "Prepare Your Software for Notarization" says:


        Enable code-signing for all of the executables you distribute.


        I take this to mean "you have to sign your application".


        A couple of points below it says "Don't use a Mac Distribution or local development certificate". The certificate we are using is of the type "Developer ID Application".


        Unless spctl is given a erroneous error message, it looks like there is at least one constraint I haven't satisfied: getting the developer id notarized.


        Nowhere in the document does it describe that process as being a constraint nor how to accomplish that task.


        The other forum topics don't address this concept at all or are ambiguous.

        • Re: spctl fails with source=Unnotarized Developer ID
          john daniel Level 4 Level 4 (500 points)

          You don't get your developer ID notarized, you notarize the app. Perhaps the wording on the output is incorrect.


          What is happening is that Catalina's spctl is behaving according to Catalina's Gatekeeper rules. That means your code needs to be notarized.


          Notarization is a well-known constraint at this point. It wasn't news a year ago and shouldn't be today.


          I had a fun little side project the other day trying to get ghostscript in 64-bit so it can drive an ImageWriter on Catalina. Normally I avoid any thread that mentions "stapling", but now I've done it. Oh, boy, now I've done it! Anyway, it's really easy, or should be.


          You will need to modify your Gradle script as follows:

          1) Change your code signing. I've seen references to people recommending against the use of "--deep". I don't know what that's about, but I see no readon to challenge it. I always try the defaults first and only use funky hacks if necessary. If this doesn't work for you, you'll have to dig deeper into code signing. You will need to use a secure timestamp and enable the hardened runtime, like so:

          codesign --timestamp --options=runtime -s "Developer ID Application: Your Company Here" -v /path/to/your/app

          2) Submit your app for notarization:

          xcrun altool --notarize-app --primary-bundle-id "com.yourcompany.whatever" --username "APPLE ID" --password "APP-SPECIFIC PASSWORD" --file /path/to/installer/package

          You might need to deal with how you are packaging the app. That's out of scope for now. You'll get an ID that you'll need for the next step if you are trying to automate this.

          3) Wait 5 minutes or so

          4) Check your status:

          xcrun altool --notarization-history 0 -u "APPLE ID" -p "APP-SPECIFIC PASSWORD"

          Check the status of your request using that ID from step 2. If not notarized yet, go to step 3. Maybe timeout after a while.

          5) Staple your ticket:

          xcrun stapler staple /path/to/installer/package

          6) Verify your signature if you want.


          You'll also get an e-mail and an Xcode notification. It might be better to switch to an asynchonrous process. I hate polling.


          There are many other threads describing any manner of custom build processes and associated last-minute notarization problems. It sounds like you will need to review a number of them. In my case I had a pkg file and it was a breeze.


          I don't know what your software does. You might also want to double-check the impact of the hardened runtime. And if you weren't already aware () there are one or two significant changes to end-user security in Catalina that you should probably investigate at this point.

            • Re: spctl fails with source=Unnotarized Developer ID
              mheins Level 1 Level 1 (0 points)

              John, thank you for your information.  I'd like to add a quick note for others who may be searching this topic:  If your developer account is associated with more than one provider, as mine is, you will also need to add another argument pair to the altool commands to specify which provider to use:  --asc-provider "providerName"   Of course, substitute an actual provider name (case sensitive) in place of "providerName".  This will avoid the following error message:  "Error Domain=ITunesConnectionOperationErrorDomain Code=1622"

            • Re: spctl fails with source=Unnotarized Developer ID
              Baudewijn Vermeire Level 1 Level 1 (0 points)

              any idea why the uploading lasts for a hour or so consistently. The Java process sits there for about 40 minutes or more, then the real upload takes place. I observe this behavior already since weeks . So roughly speaking, the notarize until the packages gets stapled, takes about an hour.
              I run the process through commands, not from within the Xcode.

                • Re: spctl fails with source=Unnotarized Developer ID
                  eskimo Apple Staff Apple Staff (12,305 points)

                  Last week, there was a specific problem with the notarisation servers running very slowly.  See this thread.  Beyond that, I’ve not noticed notarisation being particularly slow recently, and certainly not an hour slow.

                  It’s possible that what you’re submitting is triggering a problem.  Or perhaps its the place you’re submitting it from.  If I were in your shoes I’d try to tease these apart as follows:

                  • Create a simple test app in Xcode to see if that notarises quickly from your standard network.

                  • If that is still slow, try submitting that test app from a different network (like your home network) to see if it’s network specific.

                  Let us use know what you discover.

                  ps It’d help if you created a new thread for this, because your question is about notarisation performance and yhnfc created this thread to discuss getting things notarised at all.

                  Share and Enjoy

                  Quinn “The Eskimo!”
                  Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                  let myEmail = "eskimo" + "1" + "@apple.com"