So I guess this is a bug report, but there’s a couple of wider questions here.
It came up on some of the security forums that this hack/trick/feature to reveal keychain passwords still works on Sierra, and probably High Sierra too:
(though in Sierra at least you need to remove the ‘of group 1’ part in the
click command line).
Someone then mentioned that they thought Apple had made changes to stop malicious actors from scripting SecurityAgent windows, and I was sure I’d heard that too, but after doing a bit of a google searching, and searching ASUsers, I couldn’t find any mention of it.
Having tested the above-linked trick and found it worked, I wondered if maybe it was just Security windows that needed a password filled in that had been blocked, but no. In Script Editor, if I get an app to throw a password request dialog, this script will fill out the password and click the ‘OK’ button without issue:
tell application "System Events"
# repeat while exists (processes where name is "SecurityAgent")
tell process "SecurityAgent"
tell its window 1
tell text field "Password:"
set its value to <insert admin password here>
perform action "AXConfirm"
click button "OK" of window 1
# exit repeat
# end repeat
This is the kind of window I’m talking about:
In Script Debugger, however, the password is filled in, but then SD crashes (well, I should say it quits unexpectedly). Relaunching Script Debugger and running the same script again (the same Security window is still open, with the password filled in from the first run of the script), SD now clicks the button as expected and doesn’t self-terminate.
Why SE will do this in one pass without self-termination but SD doesn’t, I’ll leave to you guys to figure out! Hopefully you can reproduce it your end without the crash reports, or I’ll have to set it up on a VM machine in a virgin account.
That leads me to two questions:
did I hallucinate the whole ‘Apple blocks scripting on security windows’ thing (if so, I wasn’t the only one)?
I notice that Little Snitch windows are completely opaque to System Events and GUI scripting. Neither SD nor Accessibility Inspector can introspect them at all. How is that done? I understand that the window has to be a child of the window server to be accessible to System Events, but how is it possible to build an app with windows that AREN’T registered with the window server? Not really expecting any answers on that one, just a bit of a surprise to me that it can be done.