Privileged daemon appears as unsigned in Login Items

Just to confirm, you’re installing the daemon using SMAppService, right?

If so, that should be sufficient for the system to track the ‘responsible code’ relationship between your daemon and your app. Hmmm, assuming the daemon embedded in your app is signed the same way as the app itself.

As before, I’m going to recommend that you retry this on a ‘clean’ machine. If the problem appears there:

1. Dump the code signature of your app:

   % codesign -d -vvv /Applications/MyApp.app
   

2. Dump the code signature of the daemon embedded in the app:

   % codesign -d -vvv /Applications/MyApp.app/Contents/MacOS/MyDaemon
   

3. Check that they’re signed the same way.

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

Hello,

Yes, using SMAppService. I'm working on re-doing the test machine. (Is there a thread on how you guys recommend developers do VMs? I couldn't find one...)

In the meantime, below is the slightly redacted code sign result. (I apologize for doing things out of order.)

Thanks!

App Executable=/Applications/MyApp.app/Contents/MacOS/MyApp Identifier=com.myCompany.MyApp Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=2369 flags=0x10000(runtime) hashes=63+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=4f7273a43e951e145744876fdca528dc6dce79e6 CandidateCDHashFull sha256=4f7273a43e951e145744876fdca528dc6dce79e6802450108738a6971be08681 Hash choices=sha256 CMSDigest=4f7273a43e951e145744876fdca528dc6dce79e6802450108738a6971be08681 CMSDigestType=2 CDHash=4f7273a43e951e145744876fdca528dc6dce79e6 Signature size=9069 Authority=Developer ID Application: MyCompany () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Jun 17, 2024 at 5:16:29 PM Notarization Ticket=stapled Info.plist entries=30 TeamIdentifier= Runtime Version=14.2.0 Sealed Resources version=2 rules=13 files=9 Internal requirements count=1 size=216

Daemon: Executable=/Applications/MyApp.app/Contents/MacOS/com.myCompany.MyApp.daemon Identifier=com.myCompany.MyApp.daemon Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=1000 flags=0x10000(runtime) hashes=20+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=20f56ee32d7846e5845ee210c9a9cee20a3fcb1d CandidateCDHashFull sha256=20f56ee32d7846e5845ee210c9a9cee20a3fcb1db434afe904aa1e1e56cf9f78 Hash choices=sha256 CMSDigest=20f56ee32d7846e5845ee210c9a9cee20a3fcb1db434afe904aa1e1e56cf9f78 CMSDigestType=2 CDHash=20f56ee32d7846e5845ee210c9a9cee20a3fcb1d Signature size=9068 Authority=Developer ID Application: MyCompany (*******) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Jun 17, 2024 at 5:16:29 PM Info.plist entries=15 TeamIdentifier=***** Runtime Version=14.2.0 Sealed Resources=none Internal requirements count=1 size=220

Is there a thread on how you guys recommend developers do VMs?

No. I work for DTS and we generally stick to public-facing tools. Apple has no publicly available VM support, so I use third-party VM products. Until recently I was using VMware Fusion on my Intel Mac. Since switching to Apple silicon I’ve tried out various third-party options, and I’ve not yet settled on one for the long haul.

In the meantime, below is the slightly redacted code sign result.

Thanks. That looks fine.

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

A clean Sequoia install did address the issue. Thanks!

It does lead to the question, if an app already in production moves from SMJobBless to SMAppService, could this issue crop up for those apps? We have the luxury of shipping this app as SMAppService to start, but we have a few legacy apps that will eventually have to make the jump.

A clean Sequoia install did address the issue.

Cool.

It does lead to the question, if an app already in production moves from SMJobBless to SMAppService, could this issue crop up for those apps?

I expect so, yes. There’s also the possibility of problems occurring after an OS upgrade.

It sounds like you’re good to go, so the following is just general advice for anyone else reading along at home…

If you encounter problems like this, where the OS is not handling upgrade scenarios correctly, it’s worth filing a bug about that. It’s best if you can file a reproducible bug. So, on a clean machine, document a specific set of steps that trigger the issue. That might be something like:

1. Install a clean version of macOS V that’s never seen my software.

2. Install version N of my product.

3. Use it a bit.

4. Update it to version N+1.

5. Open System Settings and witness the horror!

If you can’t come up with reproducible steps like this then it’s fine to file a bug about the specific behaviour of one machine. Be aware, however, that such bugs are much less actionable.

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