Post not yet marked as solved
One of our pkgs has been put in notarization limbo a few times (slightly different builds each time) with the status "Processing delayed due to a service issue". The oldest instance it over 2 days old, so I'm not confident that it will ever complete.What can we do about this? I've read posts about long delays in notarization that seem to involve service outage, but this seems a bit different. Apple has inserted itself into our build/distribution process in a most inconvenient way.
Post not yet marked as solved
We have a system prefs panel that runs fine on many versions of mac OS, including Big Sur, but crashes on Monterey betas. The pref panel needs to do some IPC with a daemon process, for which it uses mach ports (and the code for that is in a shared framework outside of the prefpane bundle, if that matters).
All components of this setup are signed and notarized. We have a separate app that makes the same IPC calls as the pref panel, and it runs fine on Monterey.
The crash log shows a Termination Reason I've never seen before, and it seems that crash reporter hasn't either:
Termination Reason: Namespace <0x17>, Code 0x2000020000013507
So, should we wait for the next beta and see if things fix themselves, or bag the System Preferences environment altogether and just go with a separate app (20 years of documentation be damned)?
Post not yet marked as solved
We provide our software on a single dmg that contains several pkgs that are then used individually on customer computers. That is, the installers will usually not be run directly from the dmg. So I think the correct approach is to notarize and staple each pkg before creating the dmg. In this case, is it unnecessary to notarize the dmg?And a similar question / request for clarification: I understand that notarizing a pkg will also notarize the apps contained therein, but is it the case that we only have to staple the pkg, and this will include whatever is needed for the apps as well?Thanks for any insights,Mark
Post not yet marked as solved
We verify the signature of our install pkg files using a combination of xar calls and the crypto functions in Security framework. This has worked fine for a long time, using the productsign utility on macOS 10.11 (with Xcode 7 or 8, SDK 10.11 I think).Now we are updating our build environment to Mojave, Xcode 10, and the 10.14 SDK. The pkg files that are signed in this environment no longer pass verification using our working code. This same code (built in the new Mojave/Xcode10/SDK10..14 env) can still verify the older pkg files. But files signed with the new productsign can't be verified with our code whether that code is built in our old or new env. Of course, pkgutil shows that all the pkg sigs are valid.So... what changed in the new tools that would somehow create a non-verifiable signature? Is there any documentation on how pkg files are signed? Any docs on an Apple-sanctioned method for verifying pkg signatures programmatically? I'm happy to explain in more detail how we do this now, or post the code if that is needed.TIAMark
Post not yet marked as solved
We have a daemon process that handles requests made from apps running in user sessions. These requests are submitted via mach ports. The "client" app is third-party, so it has a different signing cert etc. Currently, the app can be sandboxed and just needs to include a particular application group entitlement, and mach port IPC works fine. However, if the app is also hardened, the IPC no longer works.Is there some new entitlement that can be added to allow such IPC to work? We would prefer not to add the complexity of a user agent that brokers requests between the client app and our system process, although I think that is one approach (with apple events or XPC). But still it would mean the user agent could not be hardened.We can jump through security hoops as needed, as long as the capability is available.
kurash.