Can't use workflow under macOS Catalina beta

[littke]

[tilmanginzel]

Hi @littke, thanks for this info! Are you still using Alfred 3 or Alfred 4 already? Someone also mentioned this issue here with a little more info, funnily also regarding this workflow.

Some notes:

• I am distributing lxml with this workflow, which apparently is blocked by Gatekepper
• It seems to be related to this: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

Maybe I need to find a replacement for lxml? Unfortunately it's quite difficult for me to reproduce it as I am still using Mojave and don't plan on using Catalina Beta anytime soon.

As a workaround, can you try installing lxml globally (STATIC_DEPS=true sudo pip install lxml) and remove the lxml folder from the workflow?

[littke]

Alfred 4. It indeed seems to work with my home computer, using Alfred 3.

I'll look into your request once I'm at work to see if it fixes it, that's where I have Alfred 4.

[tilmanginzel]

And your home computer is also using MacOS Catalina? That would be interesting 🤔

[littke]

Yep. That worked.

[tilmanginzel]

Ok thanks, I will try to test the workflow in Alfred 4 in the coming days, maybe that makes a difference.

[littke]

That worked, however:

[littke]

And oh, when I resolve that (via homebrew — look at me pretending to be a programmer! woo), I get this error:

etc etc. I think I give up on this now :)

[tilmanginzel]

Thanks for testing, you made some progress. ;) Seems like all binaries distributed with my workflow cannot be opened. :(

I tried to reprocude this (on Mojave):

• Installed Alfred 4 and migrated my workflows
• Workflow is (mostly) working as expected, blueutil and etree.so (lxml) are working
• Notification was shown via terminal-notifier
• Clicking on the notification (to retry) funnily did not work, and I received a smiliar error message that terminal-notifier.app could not be opened as my security settings did not allow to open files downloaded from the internet

I was able to do the following:

• After the error message popped up, I opened my security system preferences
• There I was able to allow terminal-notifier to be opened

Can you double-check if you have such a option after the error message comes up?

[tilmanginzel]

Regarding MacOS Catalina / Gatekeeper. I mostly think the direction Apple is taking here is noble, as they try to minimize the risk of running insecure applications. But, my gut feeling right now is that a huge amount of software must be notarized in retrospect and many applications won't work for a long time. As far as I understand, to notarize your app you must have a valid developer ID certificate, requiring you to pay $100 yearly. This won't happen for a lot of software out there. You can always disable Gatekepper, but I suppose many users won't do that.

Some articles on that:

• https://eclecticlight.co/2019/06/07/notarization-in-mojave-and-catalina/
• https://www.macobserver.com/analysis/macos-security-not-burdensome/
• https://www.idownloadblog.com/2018/10/19/gatekeeper-future-macos-notarized/
• Discussion: https://news.ycombinator.com/item?id=18260970

I found some further issues where also quite popular apps suddenly stopped working in Catalina due to this:

• https://github.com/brave/brave-browser/issues/5177
• https://github.com/Waitsnake/AnimatedGif/issues/57
• https://github.com/electron/electron/issues/18609
• https://github.com/mono/mono/issues/15333
• https://github.com/AdguardTeam/AdGuardForSafari/issues/172
• ... you can easily find endless issues for this :(

What I don't fully understand yet: Would it be enough to notarize my workflow bundle? Or is it required that each packaged binary from other developers must have been notarized too?

[littke]

Agree on all of the above.

What I don't fully understand yet: Would it be enough to notarize my workflow bundle? Or is it required that each packaged binary from other developers must have been notarized too?

Yeah, tricky question. Expensive to find out, too!

Hopefully some solution will emerge, irregardless of this plugin. Seems many others are fighting the same fight, so, something should emerge from it. Perhaps just lie low for now?

[tilmanginzel]

Yes, I will lie low for now, as I cannot really investigate this further. Once Catalina is out I can give it another try. For now, if you want to get the workflow working again (you are almost there):

brew install blueutil

And then update all ../blueutil commands in the shellscripts to blueutil. Same for terminal-notifier:

brew install terminal-notifier

And change all occurrences of ../terminal-notifier.app/Contents/MacOS/terminal-notifier to terminal-notifier in the notify.sh script. I haven't tested it, but in theory this should work then.

[avxkim]

Any updates on this? Btw, even install blueutil and changing all bash scripts in a workflow, still calling etree.so.

UPDATE

I've noticed, this works with an old version of workflow, but with latest one, like 0.5.0 gives etree.so error.

[tilmanginzel]

Hi @webcoderkz, let me start of by saying that I don't installed Catalina yet (and I am not sure when I will do), so it's difficult to reproduce and find a valid fix. This has a high priority though, as I can see that it's quite annoying if the workflow is not working.

A couple of questions:

• Is the error only related to etree.so? Or did you also see errors regarding blueutil and terminal-notifier like @littke did?
• Can you manually bypass Gatekepper? According to Apple, this still should be possible, so then you could use the workflow normally.
• In #11 you mentioned that earliers versions are working. That might be related that the new Gatekeeper features only went in full-effect for binaries published since June 2019. The other versions are quite old, so that might be the reason. etree.so was added in the first release already and did not change since.
• Do you have an idea how this can be fixed? I am very new to "MacOS" development. I do not even have an Apple ID to codesign, or even notarize, the workflow. In addition it is still unclear for me on how to proceed with the distributed binaries. Should I remove the quarantine flag on the distributed binaries and just notarize the workflow?

Appreciate any ideas!

[avxkim]

I just updated to 0.6.0 via blt workflow:update, now my airpods notification error is gone. But why this works only if i use an older version of this workflow, then update it?

[tilmanginzel]

You were too fast, see comment above. :)

[avxkim]

@tilmanginzel

1. It's related only to etree.so error. When i type blt in alfred 4, i immediately getting this error.
2. I've tried sudo spctl --master-disable, error still present.
3. Yes, earlier version does work, i just had to blt workflow:update to the 0.6.0 and everything is working now.
4. Deanishe gave you an idea on alfredforums, i suspect, it would resolve this issue.

Here's the link to an old version of this workflow: https://yadi.sk/d/85ZhICC91MmGRg that works for me.

[tilmanginzel]

Thanks for the info. I would have thought that using sudo spctl --master-disable would at least do the job (temporarily). Anyway, that would not be long term solution.

I will try to find a substitute or different approach to lxml as mentioned by Deanishe. Hopefully I can find time this week.

By the way, you can find all old releases here: releases

[avxkim]

I saw releases page, but i downloaded this workflow, like 1 year ago if i not mistaken, so i wasn't sure, which version do i actually have. Basically, your workflow is built on top of blueutil library, what does etree.so do?

[tilmanginzel]

etree.so (part of lxml) is used to parse the output of system_profiler SPBluetoothDataType -xml. The native xml libraries in python had limited XPath support, so it was much easier to use lxml. blueutil was only introduced in a later workflow version.

system_profiler SPBluetoothDataType -xml has a bit more information than blueutil (battery percentage). Maybe I should drop the battery percentage feature in favor of using only blueutil.

[tilmanginzel]

@webcoderkz Can you please check the following version: Bluetooth Connector.alfredworkflow.zip

LXML dependency was removed completely. Only blueutil is used to get device information.

[tilmanginzel]

I just downloaded that file myself, unzipped the workflow and unfortunately blueutil and terminal-notifier both have the quarantine flag set.

$ xattr blueutil
com.apple.quarantine
$ xattr terminal-notifier.app
com.apple.quarantine

So Gatekeeper will likely still complain :(

[tilmanginzel]

As a workaround for now, see: https://github.com/deanishe/alfred-sublime-text/issues/20#issuecomment-539578934

[avxkim]

@tilmanginzel well, it works with an old version, that's why i gave you a link in a previous posts. But for the new users, it would be a problem on Catalina, because neither of the new versions would work without a hemorrage.

[tilmanginzel]

I know, that's why I am looking for a solution. ;) The old version does not have the notification feature which I really like.

I will look into correctly notarizing the workflow and the distributed binaries. Maybe I can find some time for this on the weekend or the coming week.

[avxkim]

Wait, what notification features you're talking about? I have them. I have the latest 0.6.0 version of your workflow (but, as i mentioned before, i first installed an old version of workflow, then updated to an actual version with all bells and whistles).

[tilmanginzel]

Yes I am talking about that notification feature. I don't know why it is working when you download an old version first, and then upgrade. Basically we have these two options on Catalina:

• A user installs the latest version (as probably every user would do). He cannot use the workflow without hassle.
• A user first has to install an old version, and then upgrade. While this might work as an workaround, it is still a hassle which should not be required.

So I will look into a proper solution for this. Will be easier when I have installed Catalina and get a Apple Developer ID Certificate.

[avxkim]

I'm curious either, why it does work with an old version. Maybe you need to put a note in your readme with an old version, so Catalina users could use this workflow.

[deanishe]

Basically we have these two options on Catalina

As a third option, you could perhaps use the notifier API in Alfred-Workflow: it uses AppleScript, so isn't subject to the same restrictions. Of course, there's no possibility to execute a command from the notification, though, and it would suck for Catalina users to lose that feature…

[avxkim]

@deanishe do you have an idea, on why an old version of this workflow does work on Catalina?

[tilmanginzel]

As a third option, you could perhaps use the notifier API in Alfred-Workflow: it uses AppleScript, so isn't subject to the same restrictions. Of course, there's no possibility to execute a command from the notification, though, and it would suck for Catalina users to lose that feature…

Yup, I don't like to cut down on features because of this. :(

Maybe you need to put a note in your readme with an old version, so Catalina users could use this workflow.

Good point, done.

[deanishe]

do you have an idea, on why an old version of this workflow does work on Catalina?

Not really. I'm still on High Sierra. Are the contents of the old version meaningfully different?

Is it possible that Catalina "remembers" that the old version is OK because you previously allowed in under Mavericks?

[avxkim]

Dunno, i'll give it a try in a VM, to see if it's indeed remembered the old version in Mojave.

[clarkttfu]

OSX 10.15.2 + Alfred 3 + release 0.8.0, just followed steps here. Simply put, you need to authorize both workflow and "blueutil" via "Security and Privacy" and restart alfred twice.

For those who failed to start the workflow (for me, I migrated Alfred from mac to mac):

1. remove the workflow from Alfred3
2. install the workflow again.
3. start Alfred and type 'blt' to trigger call. Mac will warn you about blueutil, cancel (do not move to trash). start Security & Privacy settings, general tab to allow execution of blueutil.
4. start Alfred and type 'blt' to trigger again. This time the warning will include option to 'open' so click the open button then enjoy the workflow.

[chrisbloom7]

After installing via brew install blueutil I had to run which blueutil and then update the workflow scripts to use the full path before the workflow would work for me. This is on OSX Catalina 10.15.3 with Alfred 4.0.8

Edit: This must have been using v0.4.0 of the workflow. I just updated to the latest and it works fine without any changes

[thirteen37]

I have two options:

Allow blueutil to run

1. From the Alfred's workflow screen, right-click on "Bluetooth Connector" and select "Open in Finder".
2. Right-click on blueutil and select "Open". The warning will pop up again, but now you have the option of allowing it.
3. A terminal window will pop up and blueutil will print some stuff. You can ignore it and close the terminal.

Use Homebrew's blueutil

Similar to https://github.com/tilmanginzel/alfred-bluetooth-workflow/issues/9#issuecomment-518027027, except instead of editing each workflow script (tedious, especially if there are updates) we replace the workflow's blueutil with a soft link to /usr/local/bin/bluetooth

1. From the Alfred's workflow screen, right-click on "Bluetooth Connector" and select "Open in Terminal".
2. If you hadn't done so already: brew install blueutil
3. ln -sf /usr/local/bin/blueutil

Similar can be done with Terminal Notifier if necessary, but I didn't have any security issues with that.

A potential improvement for @tilmanginzel to consider is to have a separate wrapper script that tries to use the Homebrew version if available and fall back to the included binary.

[chrisbloom7]

At some point this stopped working for me again with a permission denied error in alfred. @thirteen37's suggestion above to Right-click on blueutil and select "Open". and then dismissing the encoding warning caused it to start working again.

[littke]

Hello again! About a year later I am back with a new macOS Beta and this time I've got good news.

Installing this on Big Sur:

• Install workflow (latest release)
• Try to run it and get an error, hit OK
• Go to Security & Privacy and Always allow
• Try to run it again, get an error, this time you can press Allow

Works! ✨

[tilmanginzel]

Thanks for keeping everyone in the loop! 👍

[jdbruijn]

Just installed on Catalina 10.15.6 and works similar to @littke's response https://github.com/tilmanginzel/alfred-bluetooth-workflow/issues/9#issuecomment-691705659! You can follow the same steps and install without any problems. Note that the error you get doesn't say to go to Security & Privacy like I believe it does for some applications, but not sure on that.

[tilmanginzel]

I am going to close this issue as the workflow is in use on Catalina (and Big Sur) for a while now. There's nothing to be done in the workflow itself, except for pointing users to the above workarounds (which is referenced in the readme).