Can someone please describe what is necessary to perform signing using codesign in a system that runs as LaunchDaemon.
All workarounds like placing the codesigning cert + private key a custom keychain and unlock it in the session of the LaunchDaemon doesn't work anymore on Sequoia.
Or are there alternatives for signing MachO binaries without codesign?
Or are there alternatives for signing MachO binaries without codesign?
No. Well, no supported alternatives.
The on-disk format used by code signing format is subject to change. If you search around on the ’net you’ll find that folks reverse engineered it, but we don’t support such endeavours.
perform signing using codesign in a system that runs as LaunchDaemon.
The only winning move is not to play (-: A launchd daemon runs as root, and signing code as root is always problematic. We even call that out in Creating distribution-signed code for macOS.
I’ve seen various folks try to work around this, but that doesn’t end well IME. Specifically, using the UserName property in your launchd property list is not a good option, because it results in your daemon running in a mixed execution context [1].
You should set up your CI server to sign code as a logged in user. There are least three ways to make this work:
-
Have the server auto login in as GUI user and start your job runner in that context.
-
Use screen sharing to start your job runner.
-
SSH in to the machine and sign your code in that context.
The last option is the most practical, and I have specific advice about it in Resolving errSecInternalComponent errors during code signing.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] For more details about macOS execution contexts, see Technote 2083 Daemons and Agents.