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"