there's nothing KM can do about the quarantine bit. MacOS sets it. Use this excellent tool to clear it: xattred, Spotcord, Metamer & xattr tools – The Eclectic Light Company
1 Like
It is macOS setting the bit, and then macOS refusing to do as it is requested when the bit is set, or to do anything useful instead.
You can clear the bit using the built in xattr shell tool.
xattr -d com.apple.quarantine path/to/file
Technically, obviously, Keyboard Maestro could simply actively clear the bit in the action, but I don't know that that is a good idea - this is an Apple system security feature (that works about as well as most of the rest of the Apple system security, which is that it stops bad things and also causes endless problems for everything else), and I don't know that Keyboard Maestro simply overriding it is something I should do.
But probably I should find a way to handle the error better.
I suppose a possible advantage of osascript -l JavaScript here is that the JS interface is late-binding in its Application references – we can supply an Application name string at run-time, rather than before compilation.
i.e. we can open a file with the Application reference, bypassing Standard Additions and (for the purposes of opening) Finder.
A rough illustration in the subroutine here:
Seems to work with, for example, Sonoma and current BBEdit builds.
1 Like
It seems I have something slightly different going on with a macro I've used for years with no problems until recently. It uses Open Finder Selection In and I get the two -128 error messages like many others. After Peter pointed me to this thread again (having forgotten that I posted previously—my Discourse settings will now keep me updated), I tried clearing the quarantine bit. xattr said there was none set, but for whatever reason, the app (a Retrobatch droplet) started working again.
However, it's failing again today in the same way with the two -128 dialogs. When I check the quarantine bit, it's still not set:
adam@2020-iMac ~ % xattr -l /Users/adam/Library/Mobile\ Documents/com\~apple\~CloudDocs/TidBITS/Tools/BorderMePro.app
com.apple.FinderInfo:
com.apple.fileprovider.fpfs#P:
And trying to clear it doesn't work:
adam@2020-iMac ~ % xattr -d com.apple.quarantine /Users/adam/Library/Mobile\ Documents/com\~apple\~CloudDocs/TidBITS/Tools/BorderMePro.app
xattr: /Users/adam/Library/Mobile Documents/com~apple~CloudDocs/TidBITS/Tools/BorderMePro.app: No such xattr: com.apple.quarantine
I can drop an image on the droplet manually and it works fine, so there has to be something related to how it's being launched by Keyboard Maestro.
Script Editor is fine -- but osascript from Terminal fails in the same way as the KM "Open Finder Selection" action, with the doubled -128 message.
Also, the first two of these actions fail but the third succeeds:
...and, IIRC, those first two also work via osascript. What about the third, @peternlewis? Perhaps osascript is the culprit?
The first two are essentially equivalent, they are using AppleScript to ask the finder to open the selection list.
The last one is quite different, it is using AppleScript to ask the finder for the selected file, and then using the system API to open the file (which presumably deals with the quarantine bit the way the Finder is supposed to, or maybe that's what Apple wants for the quarantine bit, to stop exactly this - who knows? I don't have any idea what Apple intends to be the behaviour of a file with this bit set).
<ObDisclaimer>
I'm an enthusiastic amateur, not a developer or security specialist, so view what follows with a critical eye...
</ObDisclaimer>
A perusal of Howard Oakley's most excellent Eclectic Light blog (IMO a must-read for anyone who's interested in what happens below the surface of macOS), particularly the articles on quarantine, suggests the following are relevant here:
- Apps and documents are treated differently, eg you can't clear a document's quarantine flag by opening it in the Finder and OKing a dialog
- How a quarantine flag is evaluated depends on how you open the doc -- Finder double-click and going via LaunchServices is different to explicitly choosing the non-default app via "Open with..."
- Some apps -- including, but not limited to, sandboxed apps such as Preview -- will add a quarantine flag to a document that has none
Example of the last, where stripping the flag the opening and closing the doc in Preview re-applies it:
iMac:~ nigel$ xattr -d com.apple.quarantine ~/Downloads/Scrivener_Manual-Mac-2.pdf
iMac:~ nigel$ xattr -p com.apple.quarantine ~/Downloads/Scrivener_Manual-Mac-2.pdf
xattr: /Users/nigel/Downloads/Scrivener_Manual-Mac-2.pdf: No such xattr: com.apple.quarantine
iMac:~ nigel$ open ~/Downloads/Scrivener_Manual-Mac-2.pdf
iMac:~ nigel$ # closed from Preview
iMac:~ nigel$ xattr -p com.apple.quarantine ~/Downloads/Scrivener_Manual-Mac-2.pdf
0082;66002f2b;Preview;
iMac:~ nigel$
In my testing, osascript was barfing on the usual (I was seeing 0081, 0082 or 0083) quarantine flags. But it was fine with either the flag had been deleted or if it had explicitly set to the "has been cleared by Gatekeeper" value -- 00c1.
Importantly for us, sandboxed apps seem happy to leave the 00c1 flag in the 00c- range, rather than changing it back to 008-:
iMac:~ nigel$ xattr -p com.apple.quarantine ~/Downloads/Scrivener_Manual-Mac-2.pdf
0082;66002f2b;Preview;
iMac:~ nigel$ xattr -w com.apple.quarantine "00c1;66002f2b;Preview" ~/Downloads/Scrivener_Manual-Mac-2.pdf
iMac:~ nigel$ open ~/Downloads/Scrivener_Manual-Mac-2.pdf
iMac:~ nigel$ # closed from Preview
iMac:~ nigel$ xattr -p com.apple.quarantine ~/Downloads/Scrivener_Manual-Mac-2.pdf
00c3;66002f2b;Preview
iMac:~ nigel$
...which should mean that, unlike when deleting com.apple.quarantine, we won't need to keep going back to reset the file's flag.
Putting that all together into a "Set Quarantine Flag" macro that works on a single file selected in the Finder:
Set Quarantine Flag.kmmacros (2.2 KB)
...which could easily be adjusted for multiple files, as per @NSSynapse's macro above. Or (and slightly more efficient) you could pass in a list of paths and do the loop in the shell script.
Unfortunately we can't use this automatically as part of a "Try/Catch" surrounding the "Open Finder Selection in..." action since the action itself always succeeds, even though the file's opening is blocked.
As with all quarantine adjustments, this is subverting Apple's intended (or possibly, in this case, broken!) security stance, so use wisely. Has worked in all my testing, so I'd love to hear how others get on with it.
3 Likes
FWIW, I tried moving my droplet to the Applications folder from an iCloud Drive folder. It worked. Once. Then it failed repeatedly. So I moved it back to the iCloud Drive folder. Now it works again. For how long that will last, I don't know.
No quarantine flag seems to have been set throughout all this.
I wonder if there could be some sort of LaunchServices database corruption, I might try resetting it next time this happens.
Adam, are you also checking the quarantine status of the file you're dropping? The "double error message" seems to pop up when it's the file that's the problem, not the app.
Huh! No, I haven't been checking that, but I'll do that next time it crops up. I didn't even consider that possibility because I'm creating the files in question. All of my examples are screenshots, some captured with the CleanShot X utility and others with the built-in macOS Screen Capture capability. I do have iCloud Drive's Desktop & Documents Folder syncing enabled, and all screenshots go to my desktop (which allows me to flip back and forth between two Macs seamlessly), so it's possible that's a variable as well.
OK, now I'm really confused. I got the error again when trying to border a screenshot and indeed, the quarantine flag was set:
** adam@2020-iMac ~ % xattr -l /Users/adam/Desktop/Arc\ 2024-03-25\ at\ 12.09.12@2x.png
com.apple.FinderInfo:
com.apple.lastuseddate#PS: ۡf
com.apple.macl:
com.apple.metadata:kMDItemIsScreenCapture: bplist00
com.apple.metadata:kMDItemScreenCaptureGlobalRect: bplist00?#@??
com.apple.metadata:kMDItemScreenCaptureType: bplist00Yselection
|ǭ"?m??V???V??/Ŭ????G?w?J??1<?0?܉??;?R???bfz?<?yU???4@???E?S??-??A/ں?8ˁk?ث??qDpp??e?????0=o???
com.apple.quarantine: 0081;00000000;;**
That screenshot was captured with CleanShot X, so I tried again with Apple's Command-Shift-5. No quaratine flag. But the next screenshot from CleanShot X did have one, and it was different from the first (look at the last line):
adam@2020-iMac ~ % xattr -l /Users/adam/Desktop/Arc\ 2024-03-25\ at\ 12.13.18@2x.png
com.apple.FinderInfo:
com.apple.lastuseddate#PS: ??f
com.apple.macl:
com.apple.metadata:kMDItemIsScreenCapture: bplist00
com.apple.metadata:kMDItemScreenCaptureGlobalRect: bplist00?#@?
com.apple.metadata:kMDItemScreenCaptureType: bplist00Yselection
com.apple.quarantine: 0082;6601a2a7;Preview;
Oddly, running my BorderMePro droplet around this time prompted for permission to modify files in iCloud Drive (I use Desktop & Documents Folder syncing, and I had been moving the app back and forth between my Applications folder and another iCloud Drive folder so perhaps that makes sense).
All subsequent tests have resulted in screenshots without a quarantine flag set, regardless of the app I used to take the screenshot or the app in which the screenshot was being taken.
So it does seem that this quarantine flag is the problem, but I'm completely at a loss to say why it's being set on some screenshots and not others.
This line:
...suggests the file was subsequently opened in Preview which, as a sandboxed app, reset the quarantine flag. I don't have CleanShotX so I can't dig deeper, but if you didn't open it in Preview yourself then perhaps CleanShotX uses Preview in some way.
Whatever -- while we can't (yet) get to the root cause, a solution suggests itself. You could use my "Set Quarantine Flag" macro above but modify it so it triggers when files are added to your desktop and cancels if those files aren't PNGs. That way they all get the "has passed inspection" flag, Preview (or other apps) shouldn't re-write that to the "Danger, Will Robinson!" 008[1-3] flag, and you'll avoid the "couldn't open" errors.
I may indeed have opened in Preview, or at least used Quick Look.
I'll look into tweaking your macro, thanks!
I haven't had the brain space to look into the macro yet, but I just caught Preview applying a quarantine flag red-handed. I took a screenshot, edited it, and then tried to border it, getting the error. So I tried again with a new screenshot, checking the quarantine flag before editing (not present) and after (present). But then, while writing this up, I discovered that Preview will apply the quarantine flag even if all you do is open and close the file, making no changes at all. Maddening!
I don't believe this used to be the case, but I'll have to do more testing to figure out if there are other variables.
(base) M1-MacBook-Air-2:hytek-import adam$ xattr -l /Users/adam/Desktop/CleanShot\ 2024-03-29\ at\ 15.52.14@2x.png
com.apple.FinderInfo:
com.apple.lastuseddate#PS: ?
com.apple.macl:
com.apple.metadata:kMDItemIsScreenCapture: bplist00
com.apple.metadata:kMDItemScreenCaptureGlobalRect: bplist00?#@?
com.apple.metadata:kMDItemScreenCaptureType: bplist00Vwindow
com.apple.provenance:
(base) M1-MacBook-Air-2:hytek-import adam$ xattr -l /Users/adam/Desktop/CleanShot\ 2024-03-29\ at\ 15.52.14@2x.png
com.apple.FinderInfo:
com.apple.lastuseddate#PS: ?
com.apple.macl:
com.apple.metadata:kMDItemIsScreenCapture: bplist00
com.apple.metadata:kMDItemScreenCaptureGlobalRect: bplist00?#@?
com.apple.metadata:kMDItemScreenCaptureType: bplist00Vwindow
com.apple.provenance:
com.apple.quarantine: 0082;66071bfd;Preview;
(base) M1-MacBook-Air-2:hytek-import adam$
Yes, it's a metadata change on opening -- you don't need to change or save the file itself.
It's been happening since macOS Sierra (see Quarantine and the quarantine flag – The Eclectic Light Company) but some recent security system change is causing the problems we're seeing now.
Thanks for the pointer! As Howard says:
The role and purpose of these quarantine flags added by sandboxed apps remains obscure, beyond being used to prevent the execution of shell scripts, web archives, etc. Not only that, but sandboxed apps write them, when permissions allow, to all documents which they open, even though the document may not be formally saved by that app.
Egads.
Hi @NSSynapse,
Thanks for the workaround but it fails for me with the error message: "Execute a Shell Script failed with script error: the files /- and /Sublime Text do not exist"
Can someone please provide the generic Terminal command to use for this workaround? Thanks!
Tried an Applescript workaround but got the same Error -128.
Kind regards --Mike
You've probably not quoted the path correctly -- there's a space in there and it is treating the path as (at least) two separate arguments. But you'll have to post your macro, or at least the Shell Script action, for us to be sure.
You can read more about quoting paths and other Shell Script action gotchas on its Wiki page.
1 Like
My bad, had a typo in there... Works like a charm now, so there's a workaround for now, thanks @Nige_S @peternlewis @NaOH
Cheers --Mike
2 Likes
I should have a workaround for this for the next version, essentially converting the Open the Finder Selection action into something akin to something like:
or
both of which should work in the current version.
4 Likes