Authorization by AEDeterminePermissionToAutomateTarget waits infinit time

This is working for me. I create a tiny test app with a button wired up to this code:

Code Block  
@IBAction
private func testAction(_ sender: Any) {
    self.queue.async {
        print("will ask")
        let target = NSAppleEventDescriptor(bundleIdentifier: "com.apple.TextEdit")
        let err = AEDeterminePermissionToAutomateTarget(target.aeDesc, typeWildCard, typeWildCard, true)
        print("did ask, error: \(err)")
    }
}

The first time I ran it I got the prompt. Subsequent times I got no prompt and it return an error when I switched off the setting in System Preferences. I then reset the setting using:

Code Block  
% tccutil reset AppleEvents com.example.apple-samplecode.Test666528
Successfully reset AppleEvents approval status for com.example.apple-samplecode.Test666528

and the repeated the exercise, again successfully.

I’m testing on 10.15.7 with Xcode 12.1.1. My app is not sandboxed but does have the hardened runtime enabled with the com.apple.security.automation.apple-events entitlement. The app is signed with an Apple Development signing identity. Like you, I set NSAppleEventsUsageDescription in my Info.plist.

I suggest you retry this with a new test project, just in case there’s something weird going on with your main project. If that still doesn’t work, you should open a DTS tech support incident and we can get into this in that context.

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

@eskimo thank you much , actually this is working for me as well but once in 100 times it is getting stuck and never returns. Once I restart the machine it works

this is working for me as well but once in 100 times it is getting
stuck and never returns. Once I restart the machine it works

OK that’s clearly a bug, and I recommend that you file it as such. Please post your bug number, just for the record.

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

One user of my app Remote Buddy has also reported an issue where AEDeterminePermissionToAutomateTarget does never return - despite being called with askUserIfNeeded set to false:

Code Block 
status = AEDeterminePermissionToAutomateTarget(self.targetAppEventDescriptor.aeDesc, typeWildCard, typeWildCard, false);

The sample taken with Activity Monitor eventually shows the call is hanging in a semaphore:

Code Block 
OS Version:      Mac OS X 10.15.7 (19H2)
…
    2760 Thread_6411257   DispatchQueue_10: com.apple.root.default-qos  (concurrent)
      2760 start_wqthread  (in libsystem_pthread.dylib) + 15  [0x7fff6daecb77]
        2760 _pthread_wqthread  (in libsystem_pthread.dylib) + 220  [0x7fff6daed9f7]
          2760 _dispatch_worker_thread2  (in libdispatch.dylib) + 92  [0x7fff6d8a2097]
            2760 _dispatch_root_queue_drain  (in libdispatch.dylib) + 326  [0x7fff6d8a1957]
              2760 _dispatch_queue_override_invoke  (in libdispatch.dylib) + 763  [0x7fff6d8954b0]
                2760 _dispatch_client_callout  (in libdispatch.dylib) + 8  [0x7fff6d893658]
                  2760 _dispatch_call_block_and_release  (in libdispatch.dylib) + 12  [0x7fff6d8926c4]
                    2760 __89-[ISPermissionAppleEvents _asyncDeterminePermissionAskingUserIfNeeded:completionHandler:]_block_invoke  (in ISPermissionKit) + 96  [0x1050d9e6f]
                      2760 AEDeterminePermissionToAutomateTarget  (in AE) + 1313  [0x7fff34dc7f2c]
                        2760 _dispatch_semaphore_wait_slow  (in libdispatch.dylib) + 98  [0x7fff6d893fbf]
                          2760 _dispatch_sema4_wait  (in libdispatch.dylib) + 16  [0x7fff6d893aed]
                            2760 semaphore_wait_trap  (in libsystem_kernel.dylib) + 10  [0x7fff6da2de36]

And I have found more reports of the same issue:

• answers.microsoft.com/en-us/msoffice/forum/all/1630-hangs/ef520fd6-7df0-405c-ab3b-2dde2e7db25c (including a sample as well, ending just like the one above)

• stackoverflow.com/questions/59125192/authorization-by-aedeterminepermissiontoautomatetarget-waits-infinit-time#comment114813708_59125192 (see the comments, which were posted only recently)

That to me suggests that issue is more widespread.

I have also filed a radar/feedback on this issue: FB8919870.

eskimo,

Could you please share the status of feedback ID - FB8919870?

We are still getting this error when we invoke AEDeterminePermissionToAutomateTarget() for checking automation permission. It happens randomly not every-time. But once it happens Im able to replicate it on demand.

Automation section on security & privacy shows apps in checked state only. But still API hangs. here is the call stack :

Sampling process 82676 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling iManage Application Integration (pid 82676) every 1 millisecond
Process: iManage Application Integration [82676]
Path: /Applications/iManage/iManage Application Integration.app/Contents/MacOS/iManage Application Integration
Load Address: 0x10deda000
Identifier: com.imanage.workmac2
Version: 10.3.1 (103153)
Code Type: X86-64
Platform: macOS
Parent Process: ??? [1]

Date/Time: 2021-02-11 11:37:42.374 +0530
Launch Time: 2021-02-11 11:35:39.771 +0530
OS Version: macOS 11.2 (20D64)
Report Version: 7
Analysis Tool: /usr/bin/sample

Physical footprint: 10.9M
Physical footprint (peak): 11.1M

---

Call graph:
2576 Thread1150693 DispatchQueue1: com.apple.main-thread (serial)
2576 start (in libdyld.dylib) + 1 [0x7fff20629621]
2576 main (in iManage Application Integration) + 9 [0x10dee5749]
2576 NSApplicationMain (in AppKit) + 816 [0x7fff22ee996f]
2576 -[NSApplication run] (in AppKit) + 586 [0x7fff22f1568a]
2576 -[NSApplication(NSEvent) nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit) + 1366 [0x7fff22f23177]
2576 DPSNextEvent (in AppKit) + 2048 [0x7fff22f24e3e]
2576 AEProcessAppleEvent (in HIToolbox) + 54 [0x7fff2899e5a2]
2576 aeProcessAppleEvent (in AE) + 452 [0x7fff264dd260]
2576 ??? (in AE) load address 0x7fff264d8000 + 0xc5f4 [0x7fff264e45f4]
2576 ??? (in AE) load address 0x7fff264d8000 + 0xced9 [0x7fff264e4ed9]
2576 NSAppleEventManagerGenericHandler (in Foundation) + 80 [0x7fff21466ec6]
2576 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] (in Foundation) + 308 [0x7fff21467056]
2576 -[NSApplication(NSAppleEventHandling) handleCoreEvent:withReplyEvent:] (in AppKit) + 665 [0x7fff22f2a6c7]
2576 -[NSApplication(NSAppleEventHandling) handleAEOpenEvent:] (in AppKit) + 541 [0x7fff22f2aa72]
2576 -[NSApplication sendFinishLaunchingNotification] (in AppKit) + 208 [0x7fff22f2d87b]
2576 -[NSApplication postDidFinishNotification] (in AppKit) + 305 [0x7fff22f2db2d]
2576 -[NSNotificationCenter postNotificationName:object:userInfo:] (in Foundation) + 59 [0x7fff2143****]
2576 CFXNotificationPost (in CoreFoundation) + 723 [0x7fff206ccbde]
2576 CFXRegistrationPost (in CoreFoundation) + 454 [0x7fff2079780f]
2576 _CFXRegistrationPostblockinvoke (in CoreFoundation) + 49 [0x7fff2079789b]
2576 CFNOTIFICATIONCENTERISCALLINGOUTTOANOBSERVER (in CoreFoundation) + 12 [0x7fff206fbfec]
2576 @objc AppDelegate.applicationDidFinishLaunching(:) (in iManage Application Integration) + 109 [0x10df2ef5d]
2576 AppDelegate.applicationDidFinishLaunching(:) (in iManage Application Integration) + 3594 [0x10df2dfea]
2576 Common.checkAuthforApp(processName:) (in iManage Application Integration) + 479 [0x10df3ccaf]
2576 Common.getAuthStatus(bundle:) (in iManage Application Integration) + 615 [0x10df3d5c7]
2576 AEDeterminePermissionToAutomateTarget (in AE) + 1356 [0x7fff26517921]
2576 dispatchsemaphorewaitslow (in libdispatch.dylib) + 98 [0x7fff2046412e]
2576 dispatchsema4wait (in libdispatch.dylib) + 16 [0x7fff20463c5c]
2576 semaphorewaittrap (in libsystemkernel.dylib) + 10 [0x7fff205d9eba]

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):
semaphorewaittrap (in libsystemkernel.dylib) 2576

Binary Images:
0x10deda000 - 0x10df69fff +com.imanage.workmac2 (10.3.1 - 103153) <855D845E-86F8-330D-ADB7-BC8015C15642> /Applications/iManage/iManage Application Integration.app/Contents/MacOS/iManage Application Integration
0x10e1b4000 - 0x10e407fff +com.iManage.CoreServices (10.3.1 - 103101) <1EB5CC78-81A0-31CD-8C38-E51BF91B521E> /Applications/iManage/iManage Application Integration.app/Contents/Frameworks/iManageCoreServices.framework/Versions/A/iManageCoreServices
0x10fb4a000 - 0x10fb56047 libobjc-trampolines.dylib (818.2) <29187EF9-2BD6-3ABF-8088-DE708721B612> /usr/lib/libobjc-trampolines.dylib

Could you please share the status of feedback ID - FB8919870?

AFAICT there’s no progress to report here )-:

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

I've also meet this issue several times, app stuck at calling AEDeterminePermissionToAutomateTarget, only restarting system works. I've reported as FB9030678.

I'm seeing the same thing with an app that previously worked. Radar FB9079256

1) AEDeterminePermissionToAutomateTarget no longer responds for StataSE 15. Restarting as was mentioned by @tualatrix.chou helped on the first run. Subsequent runs then failed to respond. Calling that method just goes off into the nether nether. I then tested with Microsoft Word instead of Stata. Everything worked well for Word.

2) We're also seeing some really strange behavior from the scripting bridge now - again, only with Stata in our case. When interacting with Stata if Stata is not running and must be launched then app launches and shuts down repeatedly (several times per second). Xcode is filled with the message: "Scripting Bridge could not launch application id com.stata.stata15". If Stata is already running then the AppleScript calls to it work fine. It seems to be exclusively a problem with launching applications.

My co-worker sees identical issues with Stata 16 (com.stata.stata16).

This feels really weirdly application-specific to us right now. All of this previously worked until just recently. I don't know specifically when these issues popped up, but certainly they're recent.

Quick edit: We're both using Xcode 11.0 on macOS 10.4.6. (we can't upgrade past that for a variety of reasons)

I'm seeing other messages in the console:

Code Block 
default	08:03:00.116960 -0500	StatTag	UNIX error exception: 17
default	08:03:00.122118 -0500	trustd	cert[0]: TemporalValidity =(leaf)[]> 0
default	08:03:00.123491 -0500	trustd	cert[2]: AnchorTrusted =(leaf)[force]> 0
default	08:03:00.123558 -0500	trustd	cert[0]: TemporalValidity =(leaf)[]> 0
default	08:03:00.123584 -0500	trustd	cert[0]: TemporalValidity =(path)[]> 0
default	08:03:00.123992 -0500	StatTag	Trust evaluate failure: [leaf TemporalValidity]

I'm wondering if this might have anything to do with them email from Apple re: signing:

If you’re running Xcode 11.4.1 or later, you’ll receive the updated certificate automatically when you sign an app after January 28, 2021. If you’re running an earlier release of Xcode and need to generate new certificates, download and install the new intermediate certificate and utilize the command line to sign your app. You can also archive your build with your existing Xcode version and sign it for distribution with Xcode 11.4.1 or later. 

Updated to macOS 11.2.3 and Xcode 12.4. Same behavior.

I find a simple way to reproduce this issue with 100%, and I've reported FB9126429.

Please follow these steps:

• Open Apple Music. After that, press CMD+W, make sure there’s no window for Apple Music is opened.
• Click Apple Logo and choose “Log out”, make sure the “Reopen windows” is checked.
• After login again, you will see Apple Music is appearing the Dock, and no window is open. That’s correct.
• If you open Activity Monitor, you will see Apple Music with 8KB memory

Do not try to click Apple Music Icon on Dock, now open the project of TestAEDeterminePermissionToAutomateTarget, build and run. Click the “Grant Permission” button. You will see the App stuck at the method of AEDeterminePermissionToAutomateTarget, with semaphore_wait_trap method call.

If you click the Apple Music Icon on Dock, Apple Music will launch normally, then build and run the again, everything will work fine.

I hope these steps will be helpful so that this bug will be fixed soon. Thanks.

---

Since I can't upload the Xcode project, here's the core code, you can build your own demo in seconds.

let bundleIdentifier = "com.apple.Music"

let targetAppEventDescriptor = NSAppleEventDescriptor(bundleIdentifier: bundleIdentifier)

let status = AEDeterminePermissionToAutomateTarget(targetAppEventDescriptor.aeDesc, typeWildCard, typeWildCard, true)

debugPrint(status)

I find a simple way to reproduce this issue with 100%, and I've reported FB9126429.

Thank you!

I’ve update our ‘lead bug’ with a reference to your new bug and your steps to reproduce.

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

Any updates on that? I'm hitting the problem, while trying to analyse my problem reported on StackOverflow: https://stackoverflow.com/questions/70802857/cannot-send-a-keystroke-in-swift-gui-application-on-macos-11-6-big-sur-comm (Any hints for that issue are welcome as well :-) )

Any updates on that?

No.

Having said that, I can’t see any connection between AEDeterminePermissionToAutomateTarget and sending key events. Key events are different from Apple events and controlled by different TCC gates [1].

Oh, in the post you referenced you wrote:

Disabled App Sandbox:

<key>com.apple.security.app-sandbox</key>
<false/>

Do not set Boolean entitlements to their default values. In many cases this doesn’t actually disable the entitlement! I just (like yesterday :-) added this note to Hardened Runtime docs:

The default value of these Boolean entitlements is false. When Xcode signs your code, it includes an entitlement only if the value is true. If you’re manually signing code, follow this convention to ensure maximum compatibility. Don’t include an entitlement if the value is false.

The same applies to App Sandbox entitlements.

If the above doesn’t help, you should start a new thread here and I’ll take a proper look. Make sure to tag it with Privacy so that I see it.

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

[1] Except if you script System Events to send key events, but that’s not what you’re doing here.

I filed this back in April, 2019 (FB5345023). I've found that if I bring the target to the front with NSRunningApplication.activateWithOptions before calling AEDeterminePermissionToAutomateTarget, the hangs don't occur. So that's a workaround, though ugly, depending on your use-case.