Post not yet marked as solved
This question came from https://developer.apple.com/forums/thread/695826, where I saw crashes in AppKit if called without a GUI session. What troubles me from there is that our code is registered as a LaunchAgent (under /Library/LaunchAgents), and I was under the impression that a LaunchAgent only runs if a user logs into a GUI session. I tried at least ssh-only sessions and didn't see it launch automatically (I had to manually launch it through ssh to reproduce the crash). But the fact that we see thousands of crash reports coming from a few devices means somehow our LaunchAgent is trying to launch itself automatically & repeatedly on these devices, while there is no GUI session so it keeps crashing.
So, maybe there is a legit way to reproduce the scenario, to launch a LaunchAgent without a GUI session that I'm not aware of?
Post not yet marked as solved
We've seen some crash logs coming from a few of our product users. The unique device count having this issue is pretty low but 1 of them generated 35K crash logs. And so far all of the logs have been coming from macOS 12.0.1 (21A559) build. The crash stack ended at "NSCGSPanicv" in AppKit. Any pointers on what to make sense of this will be appreciated.
Thread 0 (CRASHED)
0 AppKit 0x00007ff80c9837b6 NSCGSPanicv (in AppKit) + 261
1 AppKit 0x00007ff80c9836b1 NSCGSPanicv (in AppKit) + 0
2 AppKit 0x00007ff80c7983d4 +[NSCGSStatusItem statusItemWithWindowID:confiningDisplayID:flags:priority:systemInsertOrder:preferredPosition:appearance:] (in AppKit) + 0
3 AppKit 0x00007ff80c798402 +[NSCGSStatusItem statusItemWithWindowID:confiningDisplayID:flags:priority:systemInsertOrder:preferredPosition:appearance:] (in AppKit) + 46
4 AppKit 0x00007ff80c6ada6e -[NSStatusItem _wakeStatusItem] (in AppKit) + 316
5 AppKit 0x00007ff80c1f4394 -[NSStatusBar _statusItemWithLength:withPriority:] (in AppKit) + 95
... (our product code stack below)
The way by which our code is calling into AppKit is like this -
[[NSStatusBar systemStatusBar] statusItemWithLength:NSSquareStatusItemLength];
Post not yet marked as solved
We noticed from the Monterey Beta 8/Beta 9 release notes that -
Support for cleartext HTTP URL schemes for Proxy Automatic Configuration (PAC) is now deprecated. Use only HTTPS URL schemes for PAC. This affects all PAC configurations, including, but not limited to, configurations set via Settings, System Preferences, profiles, and URLSession APIs such as connectionProxyDictionary and CFNetworkExecuteProxyAutoConfigurationURL(::::). If you configure a cleartext HTTP PAC URL, the system may upgrade it to HTTPS during PAC file loads. Web Proxy Auto-Discovery (WPAD) Protocol via DNS isn’t affected. Dynamic Host Configuration Protocol (DHCP) Option 252 WPAD may attempt to upgrade cleartext HTTP URLs to HTTPS during PAC file loads. (61981845)
We have a product that delivers a PAC file through http://localhost, we verified with Beta 8 and Beta 9 builds this didn't cause any problem. The question is, is this expected? The release notes make it sounds like the deprecation is enforced, or maybe this is because we are using "localhost"? If it's expected, are we going to keep this behavior in the final release?
(Because it's pretty late for us to fix the HTTP scheme in time for our product now. We'd be happy if we can get away with it for now and plan for a proper fix in the next release.)
Hi, we've come to notice that macOS will always do a password prompt even if our app is trying to deactivate our own system extension. There are other posts on this topic as well and we're probably going to have to accept this fact.
However, a separate scenario that's bothering us is that, even if we have a MDM profile that whitelists our system extension (so that activating it doesn't require user interaction), we still get password prompts when trying to uninstall it. We're going to file a support ticket for this but before that we want to see if we can get some quicker response here, is this the current expected behavior or maybe are we doing something wrong in our MDM profile?
Thanks!
qb_s.