spctl fails with source=Unnotarized Developer ID

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.

Hi;
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.

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"

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"