Multi-machine Code Signing

I have two Macs, desktop and laptop. Since they both belong to me, they both sign in with the same Apple account. I find that if I sign and notarize an app on one, the other must be powered off. Otherwise, notarization will fail.

Is this intentional? If so, what is the rationale? Is there a way to fix or avoid it?

Both systems run macOS Tahoe with the latest updates. Both are set up the same way for signing using the same certificates. The build process is identical on each.

Answered by DTS Engineer in 871883022
It's rather something about rebooting the machine that makes the magic work.

OK, that definitely rings some bells. Consider the issue described in Updating Mac Software. If you’re copying code around with tools that overwrite the code file rather than replace it, you can run into all sorts of weird problems like this.

Share and Enjoy

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

notarization will fail

In what way?

Given that we’re talking about notarisation, that means Developer ID signing, and I have some general advice on that topic. See The Care and Feeding of Developer ID.

As to your main issue, you wrote:

Otherwise, notarization will fail.

That’s not giving us a lot to go on. Which step fails? And how does it fail? What error is reported?

Speaking generally, I’m not aware of anything that would cause notarisation to fail in this situation. Lots of developers notarise from multiple machines, for example, in CI/CD systems. Given that, I suspect that there’s something weird going on with your setup specifically.

Share and Enjoy

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

Thanks for the replies. You are both quite right that I should have provided more information.

When I say that notarization succeeds, I mean that I submit the dmg file produced by the build to the Apple notarization service and receive a status of 'Accepted'. I take this to mean all is well.

When I say that notarization fails, I mean that the notarization step produces a status of 'Invalid'. Retrieving the notarization log indicates that the binaries were not signed.

I've just gone through this again with my two machines. The build here is performed by scripts that are maintained in source code control and forced to be identical in both setups. The build infrastructure is also the same for both. Before beginning, both machines were powered off for a period of time.

  1. Power up one machine. Ensure the source tree is up-to-date. Run the build to produce a signed dmg. Submit it for notarization. The submission produces a status of Accepted.

  2. Power down the first machine. Power up the second machine. Again ensure the source tree is up-to-date. Run the build to produce the signed dmg. Submit it for notarization. The submission produces a status of Invalid. The notarization log indicates the binaries are not signed.

  3. Reboot the second machine and do the process again. This time the dmg is Accepted by notarization.

I've run variations on this set of steps. The only way I have been able to build things reliably is to use one machine at a time.

Signing relies on my Developer ID Application and/or Installer certificates. They are present in Keychain Access with private keys, intermediate certs and the root cert. I don't think signing would ever succeed if this setup were not valid.

Since the notarization log may say the binaries are not signed, you may well ask how they are being signed. This build does not use Xcode at all. It is a Java application and uses the Java jpackage tool to produce the signed dmg. You may at this point say 'Aha' and wash your hands of me. Internally, however, I believe this tool calls the Apple codesign tool. I have other builds that call codesign directly and show similar behavior.

Independently detecting whether a binary or an installer is signed correctly seems to be difficult. I have tried several tools with mixed results. Some will say yes, some no, on the same file. I would welcome a definitive way to do it.

After playing with builds and code signing over this weekend, I'm now not sure my original idea about this failure is correct. It's rather something about rebooting the machine that makes the magic work.

If I work on a source tree, editing files, checking things into and out of source code control, performing builds or parts of builds, etc., code signing the final build often fails. If I reboot the system and make the full build right away, before doing anything else, it works. Some tool that I use must be corrupting it.

Unless someone knows ways to interfere with code signing that might align with this, I will take this away and try to gather more information. Thanks for your help so far.

It's rather something about rebooting the machine that makes the magic work.

OK, that definitely rings some bells. Consider the issue described in Updating Mac Software. If you’re copying code around with tools that overwrite the code file rather than replace it, you can run into all sorts of weird problems like this.

Share and Enjoy

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

Multi-machine Code Signing
 
 
Q