Notarization issue with keys

Follow up:

# Machine where notarization is done:
% sudo spctl -a -t install -vvv example.pkg
example.pkg: accepted
source=Notarized Developer ID
origin=Developer ID Installer: company name (ABCXYZ123)

# Same package, different machine:
% sudo spctl -a -t install -vvv example.pkg
example.pkg: rejected
source=Unnotarized Developer ID
origin=Developer ID Installer: company name (ABCXYZ123)

I’m not sure I understand what you’re getting at here. You wrote:

The notarization result shows as successful

If notarisation is successful then you don’t have a problem with your authentication. If you did, you wouldn’t even be abel to submit a notarisation request.

However, when the package is transferred to another system, it is displayed as not notarized.

How are you testing that? I use the process described in Testing a Notarised Product. It’s the best way to verify the behaviour that you’re customers are going to see.

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

Hello @DTS Engineer This is what we do:

# Executing the command on the machine where the notarization was performed via API Key:
% sudo spctl -a -t install -vvv PackageName.pkg
PackageName.pkg: accepted
source=Notarized Developer ID
origin=Developer ID Installer: OrgName (ID)
 
# The same package is copied to another machine (e.g. via scp). Executing the same command on the same package on another machine:
% sudo spctl -a -t install -vvv PackageName.pkg
PackageName.pkg: rejected
source=Unnotarized Developer ID
origin=Developer ID Installer: OrgName (ID)

@DTS Engineer Hello,

Seems I accidentally pressed, "Accept Answer", but in reality, topic is still open for me :)

Looking forward to hear your comments.

Thanks, Rovshan

Seems I accidentally pressed, "Accept Answer”

No worries. Sadly, there’s no way to undo that (r. 113568518), but it doesn’t matter to me, because I don’t pay much attention to that flag.

This is what we do:

OK, so that’s not a good way to test this. Quoting the post I linked to previously:

The process described above is by far the best way to test your Gatekeeper compatibility because it accurately tests how your users run your product. However, you can also run a quick, albeit less accurate test, using various command-line tools [like spctl]

In short:

• Running spctl is not the best way to check for Gatekeeper compatibility.

• It’s better to do a user-level test on a ‘clean’ VM, one that’s never seen your product before.

I suspect that the only problem you have here is your testing methodology.

ps Running security tools, like spctl, using sudo as a matter of course is a bad idea.

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

Hello @DTS Engineer Let me do more checks as you said.

I will post my feedback asap.

Hello @DTS Engineer, We did following, but still facing issue:

14:04:39 + xcrun notarytool submit --key **** --key-id 123456789 --issuer abcd-efgh-1234 --wait './name.pkg'14:04:39 Conducting pre-submission checks for name.pkg and initiating connection to the Apple notary service...14:04:41 Submission ID received14:04:41 id: abcd-efgh-1234 14:04:56 Successfully uploaded file14:04:56 id: abcd-efgh-1234 14:04:56 path: name.pkg14:04:56 Waiting for processing to complete.14:06:56 Current status: In Progress... Current status: In Progress.... Current status: In Progress..... Current status: In Progress...... Current status: In Progress....... Current status: In Progress........ Current status: In Progress......... Current status: In Progress.......... Current status: In Progress........... Current status: In Progress............ Current status: In Progress............. Current status: In Progress.............. Current status: In Progress............... Current status: Accepted................Processing complete14:06:56 id: abcd-efgh-1234 14:06:56 status: Accepted

And on other macOS we tried to open package:

Well, that’s interesting. While successfully notarising a product doesn’t guarantee that it’ll pass Gatekeeper, it’s rare to run into Gatekeeper problems when opening an installer package (as opposed to when launching an app).

To debug this I need the following:

• A copy of the installer package you submitted to the notary service.

• A copy of the notary log, as explained in Fetching the Notary Log

Make sure that the SHA-256 checksum of the first matches the SHA-256 checksum in the second.

If you can post these publicly, that’d be grand. See tip 14 in Quinn’s Top Ten DevForums Tips for info on how to post a URL.

If not, let me know and I’ll suggest an alternative path.

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

Hi @DTS Engineer

We also ran following command and after that notarization worked:

xcrun stapler staple ./test.pkg

You mean “after that you were able to install the package”, right?

If so, that’s surprising. The system is usually able to download tickets from Apple on demand, and thus doesn’t need stapling. I discuss this in more detail in The Pros and Cons of Stapling.

However, if stapling fixes the issue then that sounds like a solution. There’s certainly nothing wrong about doing this stapling.

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