StatTag unable to bring up Stata when closed

[lrasmus]

During development of #26, I noticed that StatTag couldn't bring up Stata if it was fully closed. I can see in the debug output:

Scripting Bridge could not launch application id com.stata.stata16.

I disabled Stata16 and tested with Stata15 with the same behavior. Need to confirm if this is something specific to my machine, or possibly a larger problem.

[lrasmus]

This was tested in debugger of Xcode8 on macOS 10.13.6

[lrasmus]

As a note, the following AppleScript works just fine in launching Stata16:

tell application "StataIC"
	DoCommandAsync "clear all"
	set nReturn to DoCommandAsync "blah"
	set bResult to UtilIsStataFree
	repeat while bResult is false
		set bResult to UtilIsStataFree
	end repeat
	display dialog ((nReturn) as string)
end tell

[ewhitley]

I'm now seeing the same issue with the latest security updates on macOS 10.14.6.

I think it's got to do with the permissions check -
https://github.com/StatTag/StatTagMac/blob/notarizing/StatTagFramework/StatTag/ViewControllers/STPrivacyConsentController.m#L72

OSStatus appleScriptPermission = AEDeterminePermissionToAutomateTarget(&addressDesc, typeWildCard, typeWildCard, promptIfNeeded);

• Works fine when checking the Word bundle ID - com.microsoft.word
• Just spins off into nowhere when checking stata - com.stata.stata15

[ewhitley]

@lrasmus is that on the Notarizing branch? That's where we have the privacy controller check

[lrasmus]

Oh! Okay sorry, it is not on the notarizing branch. That didn't build on my 10.13, so I was using develop. Let me get this set up on my test environment where I can check the notarizing code. Thanks for pointing that out.

[lrasmus]

Confirming on my 10.14 setup (Stata15) using the Notarizing branch that this fails

[ewhitley]

Two issues:

1. Privacy check no longer works with Stata. Other apps seem to work (ex: Word). This previously worked. Permission check issued, but we never receive a response.
2. If Stata is not already running, then StatTag cannot launch it. App goes into weird spiral of open/close due to AppleScript permissions refusal. NOTE: automation IS enabled / allowed for StatTag -> Stata on my machine. If Stata IS running (and you disable the privacy check) then StatTag can communicate with Stata.

Weird.

[ewhitley]

We're not alone

https://developer.apple.com/forums/thread/666528

[ewhitley]

Tried using a background thread w/ GCD, but on change. Word returns fine, but Stata 15 freaks out.

[ewhitley]

This gets weirder.

STEP 1

• Restarted OS
• Manually started StataSE
• Re-Ran StatTag (Xcode)
• WORKED - received privacy response from AEDeterminePermissionToAutomateTarget - all ran OK

STEP 2

• Quit StatTag (Xcode)
• Quit StataSE
• Re-Ran StatTag
• StataSE would not run and kept bouncing in the dock. Console listed error as "Scripting Bridge could not launch application"
• Quit StatTag (Xcode)

STEP 3

• Started StataSE
• Re-Ran StatTag
• Went off into ether on privacy check

From here on out, will no longer get a privacy response from AEDeterminePermissionToAutomateTarget

1. Why can we no longer launch StatSE through the bridge?
2. Why would we need to restart the OS to get AEDeterminePermissionToAutomateTarget to work for StataSE?

[ewhitley]

RADAR issue FB9079256 opened

==========

Basic Information

Please provide a descriptive title for your feedback:
Privacy API call to AEDeterminePermissionToAutomateTarget never returns, third party app no longer able to be launched from AppleScript

Which area are you seeing an issue with?
Foundation

What type of issue are you reporting?
Incorrect/Unexpected Behavior

Description
Please describe the issue and what steps we can take to reproduce it:

Apologies if this is targeted to the wrong team, but I can't quite tell where this should go.

• Xcode 11.0
• macOS 10.14.6 (developer machine)
• Third party apps:
  • Microsoft Word 2016
  • StataSE 15
• Languages:
  • Objective C
  • AppleScript

We've been using AppleScript to call out to applications:

• Microsoft Word 11 and 2016+
• Stata 15

Our application (https://sites.northwestern.edu/stattag/) uses AppleScript to call into these applications to gather statistical results (from Stata) and to update content in Word documents (this is for an NLM government research grant). We use the AppleScript scripting bridge to communicate with third party applications.

We have been doing this since approximately 2015 without issue. Recently we updated our code to make use of the privacy APIs so we can determine if scripting is enabled when communicating with third party applications. This was working fine until just recently when we started experiencing two potentially related issues (hence the single ticket):

ISSUE - AEDeterminePermissionToAutomateTarget does not consistently respond

EXPECTATION

Calls to AEDeterminePermissionToAutomateTarget should return a value

ACTUAL

In some cases there is no response from the API call.

DETAILS

Calling out to the privacy API for Stata no longer responds. The line runs, but never seems to continue:

 OSStatus appleScriptPermission = AEDeterminePermissionToAutomateTarget(&addressDesc, typeWildCard, typeWild  Card, promptIfNeeded);

Calling that same line for Microsoft Word always seems to work. Weirdly, restarting the entire OS allows that line to run ONCE and ONLY ONCE. Once we quit our app or Stata then running that line again exhibits the same "never responds" behavior.

ISSUE - Attempting to launch an app from the Scripting Bridge returns an error "Scripting Bridge could not launch application"

EXPECTATION

Apps should be launchable from within the Scripting Bridge if the appropriate permissions are granted

ACTUAL

Certain apps do not seem to be launching correctly and are giving us the error: "Scripting Bridge could not launch application"

DETAILS

For no reason we can grasp we can no longer launch Stata successfully from AppleScript within Xcode.

• If we disable the privacy check, grant scripting access to Stata from our app, and then launch the app, everything works
• If we attempt to LAUNCH the third party app from within our app we receive the following error: "Scripting Bridge could not launch application id com.stata.stata15"

We have no idea why we can no longer launch Stata from AppleScript. This previously worked without issue.

[ewhitley]

@lrasmus - I don't know if this is related, but I just sent more data to Apple on that ticket

1. disabled the privacy check so I could run Stata integration
2. Made sure Stata was closed and then started a Stata-baesd tag update through StatTag

Seeing this in the console

default	08:03:16.749469 -0500	loginwindow	-[PersistentAppsSupport applicationReady:] | App: StataSE, ready, updating active tracking timer
default	08:03:16.749800 -0500	loginwindow	-[ApplicationManager checkInAppContext:refCon:eventData:] |      checked in app : StataSE
default	08:03:16.751357 -0500	distnoted	register name: com.apple.sharedfilelist.change object: com.apple.LSSharedFileList.ApplicationRecentDocuments/com.stata.stata15 token: f451a pid: 397
default	08:03:16.954903 -0500	StatTag	Scripting Bridge could not launch application id com.stata.stata15.
default	08:03:16.961377 -0500	loginwindow	-[PersistentAppsSupport applicationQuit:] | for app:StataSE, _appTrackingState = 2
default	08:03:16.961405 -0500	loginwindow	-[PersistentAppsSupport applicationQuit:] | App: StataSE, quit, updating active tracking timer
default	08:03:17.089464 -0500	loginwindow	-[PersistentAppsSupport applicationReady:] | App: StataSE, ready, updating active tracking timer
default	08:03:17.090066 -0500	loginwindow	-[ApplicationManager checkInAppContext:refCon:eventData:] |      checked in app : StataSE
.....

default	08:03:31.904987 -0500	ReportCrash	Saved crash report for StataSE[5190] version 15.0.591 (15.0.591) to StataSE_2021-04-15-080331_FlashBook-Pro.crash
default	08:03:31.905713 -0500	ReportCrash	Saved crash report for StataSE[5192] version 15.0.591 (15.0.591) to StataSE_2021-04-15-080331-2_FlashBook-Pro.crash
default	08:03:31.905926 -0500	ReportCrash	Saved crash report for StataSE[5191] version 15.0.591 (15.0.591) to StataSE_2021-04-15-080331-1_FlashBook-Pro.crash
default	08:03:31.908029 -0500	ReportCrash	Saved crash report for StataSE[5193] version 15.0.591 (15.0.591) to StataSE_2021-04-15-080331-3_FlashBook-Pro.crash
default	08:03:31.964895 -0500	ReportCrash	Saved crash report for StataSE[5194] version 15.0.591 (15.0.591) to StataSE_2021-04-15-080331-4_FlashBook-Pro.crash

so I checked the crash logs (~/Library/Logs/DiagnosticReports/)

I thought this was interesting

Termination Reason:    DYLD, [0x4] Symbol missing

Application Specific Information:
dyld: launch, loading dependent libraries
DYLD_FRAMEWORK_PATH=/Users/ewhitley/Library/Developer/Xcode/DerivedData/StatTag-diwaeljxtvfzfaguuevotjchydoz/Build/Products/Debug-iphoneos:/Users/ewhitley/Library/Developer/Xcode/DerivedData/StatTag-diwaeljxtvfzfaguuevotjchydoz/Build/Products/Debug
DYLD_LIBRARY_PATH=/Users/ewhitley/Library/Developer/Xcode/DerivedData/StatTag-diwaeljxtvfzfaguuevotjchydoz/Build/Products/Debug-iphoneos:/Users/ewhitley/Library/Developer/Xcode/DerivedData/StatTag-diwaeljxtvfzfaguuevotjchydoz/Build/Products/Debug:/usr/lib/system/introspection

Dyld Error Message:
  Symbol not found: _SCIDidDropFilenamesNotification
  Referenced from: /Applications/Stata/StataSE.app/Contents/MacOS/StataSE
  Expected in: /Users/USER/Library/Developer/Xcode/DerivedData/StatTag-diwaeljxtvfzfaguuevotjchydoz/Build/Products/Debug/Scintilla.framework/Versions/A/Scintilla
 in /Applications/Stata/StataSE.app/Contents/MacOS/StataSE

Binary Images:
       0x10efbb000 -        0x110271ff7 +com.stata.stata15 (15.0.591 - 15.0.591) <FE945912-3BFD-306D-9FFB-A1AF47D047A0> /Applications/Stata/StataSE.app/Contents/MacOS/StataSE
       0x110f68000 -        0x111389fff +com.sun.Scintilla (4.4.6 - 4.4.6) <D7F28267-B77E-32D7-A504-A2A33706E70F> /Users/USER/Library/Developer/Xcode/DerivedData/StatTag-diwaeljxtvfzfaguuevotjchydoz/Build/Products/Debug/Scintilla.framework/Versions/A/Scintilla
       0x111a98000 -        0x111ae0fff  libdispatch.dylib (1008.270.1) <25286E49-4EBF-3D8C-88FB-9D6B2E508B61> /usr/lib/system/introspection/libdispatch.dylib
       0x111b16000 -        0x111b23fff  libsystem_pthread.dylib (330.250.2) <7F595064-9E17-3A57-ADB1-E0BFEE863DCB> /usr/lib/system/introspection/libsystem_pthread.dylib
       0x11714d000 -        0x1171b770f  dyld (655.1.1) <EA5BF483-08FB-31C9-B31E-C0D0FD94FE89> /usr/lib/dyld

[ewhitley]

@lrasmus interesting. Also seeing a ton of these

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]

Which makes me wonder about this email from earlier:

Starting January 28, 2021, the digital certificates you use to sign your software for installation on Apple devices, submit apps to the App Store, and connect to certain Apple services will be issued from a new intermediate Apple Worldwide Developer Relations certificate (expiring 2030). This new intermediate certificate will not affect the availability or functionality of apps you’re already distributing on the App Store. And you can continue to use your existing certificates until they expire.

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.