I have the same problem. System says there's an update available, I'm trying to install it, it starts, but ends with an error. When running softwareupdate -ai under the console, I need to start it from a normal user (can't start it from root because if I do that, it starts asking for a password of some user that doesn't exist), it ends rather quickly with an error: Failed to download & prepare update: Error Domain=SUMacControllerError Code=7721 "[SUMacControllerErrorPreflightWakeupFailed=7721] Failed to perform PreflightWakeup operation: [MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_INTERNAL_ERROR(7)]" UserInfo={NSUnderlyingError=0x14ee05710 {Error Domain=MobileSoftwareUpdateErrorDomain Code=7 "No service connection" UserInfo={NSLocalizedDescription=No service connection}}, SUMacControllerErrorIndicationsMask=0, NSDebugDescription=[SUMacControllerErrorPreflightWakeupFailed=7721] Failed to perform PreflightWakeup operation: [MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_INTERNAL_ERROR(7)], NSLocalizedDescription=Failed to launch the software update installer. Please try again.} Tried both on Wi-Fi and wired connection, there's no problem with the Internet connection (I'm writing this post from the same machine).

@tpetdoctor -- did it work? Can you post an update?

Can't edit the post, so I'll just add more info here: The example in the post has been checked on macOS M1 12.2 and 12.6, and it's triggering there. I've also checked on 10.15.7 (19H1217) on AMD64, and it's NOT active there. There's no crash/kill on this OS version.

Sorry, I didn't realize that I'm using a disallowed word. Instead of it, I would suggest to use "raw MachO files", that is a MachO file that do not belong to any bundle.

I can't edit the post, so I'm ussing this comment as an errata: I've already written one comment about this, but it got removed by the Forums. Those stars do not represent any offensive word. It got censored by the Forums, but a synonim would be e.g. "raw", or "direct", or "bundle-less".

Yes, the app uses dlopen(3) and dlclose(3).

Thanks for the answer @eskimo! It did clear some things up, but not everything. I'm still trying to figure out how stapling should work with an app that auto-updates itself. Let's say I have an app bundle "A.app" with 2 components: an executable "E", and a dylib file "D". I notarize the whole "A.app" bundle, and I staple it -- this part is clear. Then, I create a new app bundle "B.app", that has its own executable "E1" and the component "D" (its file has the same SHA1 as used in "A.app"). I notarize "E1" executable. I don't staple "B.app". So the questions are: Should I assume that "D" component inside "B.app" is already notarized (because it was notarized in the process of notarizing the whole A.app bundle)? Or should it be notarized once again, since it's exactly the same component as in "A.app", but now is included inside a different app bundle: "B.app"? Since I don't staple "B.app", I now depend on the system to automatically download missing staples from Apple's servers. But I never notarized the whole "B.app", I've just notarized "E1" separately, and notarized "D" as part of notarization of the whole "A.app" bundle. Is the system able to even download any notarization proofs in this case? Notarisation checks typically only kick in if your code is quarantined and the software update system within your app doesn’t have to quarantine anything. Do you know if it will stay like this in the future as well?

Yes, "E1" would be the main executable for "B.app". Does the notarization system assume only bundles will be notarized? Will there be a problem (now or in the future) with notarization of individual executable/dylib files? (I understand that since "E1" would be a main executable for "B.app", then the way it should be done is to notarize the whole "B.app" bundle. But I'm interested in knowing how it looks like from Apple's perspective if I notarize "E1" individually, notarize "D" when it was a part of a different app bundle, and I don't notarize "B.app" at all).

Did you eventually get a response? We will probably need to request the entitlement in the future, but seeing that others have to wait over 5 months is very worrying and I think we need to request for it in advance.

Hello, did you eventually get a response from Apple?

Thanks. I've created FB13677854. However, the feedback reporting system has completely garbled up the formatting of the description, so it's not very readable.

Thanks for the information, it's really useful. Although, do you know if macOS data providers will be more restricted in the future? I mean, is it intentional that data providers on macOS are less restrictive than on iOS? Or is it a temporary state, and they will be more restricted in future versions of macOS, to make it more similar to their iOS versions? In other words, is it safe to base our business logic on that? (Because if you choose to restrict data providers in future versions of macOS, then our whole product will fail.)

I think that for _AUTH_OPEN events you need to respond with es_respond_flags_result() instead of es_respond_auth_result()? Also, the last argument to es_subscribe() can be wrong, it probably should be 1 instead of sizeof(eventTypes) (Apple code is buggy in several examples).

Here's one relevant answer: https://developer.apple.com/forums/thread/649552?answerId=615802022#615802022 Every time someone asks for a longer deadline we actually make it slightly shorter. I guess now it will be 14 seconds :)

Created FB15589338. True, I should call copyfile(3) a function, not a syscall. But still the point of my post holds for this case -- Apple has previously replied to us that the _COPYFILE event is emitted when the copyfile(3) is called. Not (2).